linux-stable.git/net, branch linux-2.6.35.y

IGMP snooping: set mrouters_only flag for IPv6 traffic

2011-08-01T20:55:04+00:00

[ upstream commit fc2af6c73fc9449cd5894a36bb76b8f8c0e49fd8 ]
 properly

Upon reception of a MGM report packet the kernel sets the mrouters_only flag
in a skb that is a clone of the original skb, which means that the bridge
loses track of MGM packets (cb buffers are tied to a specific skb and not
shared) and it ends up forwading join requests to the bridge interface.

This can cause unexpected membership timeouts and intermitent/permanent loss
of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:

    A snooping switch should forward IGMP Membership Reports only to
    those ports where multicast routers are attached.
    [...]
    Sending membership reports to other hosts can result, for IGMPv1
    and IGMPv2, in unintentionally preventing a host from joining a
    specific multicast group.

Signed-off-by: Fernando Luis Vazquez Cao 
Signed-off-by: David S. Miller 
Signed-off-by: Andi Kleen

IGMP snooping: set mrouters_only flag for IPv4 traffic

2011-08-01T20:55:04+00:00

[ upstream commit 62b2bcb49cca72f6d3f39f831127a6ab315a475d ]
 properly

Upon reception of a IGMP/IGMPv2 membership report the kernel sets the
mrouters_only flag in a skb that may be a clone of the original skb, which
means that sometimes the bridge loses track of membership report packets (cb
buffers are tied to a specific skb and not shared) and it ends up forwading
join requests to the bridge interface.

This can cause unexpected membership timeouts and intermitent/permanent loss
of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:

    A snooping switch should forward IGMP Membership Reports only to
    those ports where multicast routers are attached.
    [...]
    Sending membership reports to other hosts can result, for IGMPv1
    and IGMPv2, in unintentionally preventing a host from joining a
    specific multicast group.

Signed-off-by: Fernando Luis Vazquez Cao 
Tested-by: Hayato Kakuta 
Signed-off-by: David S. Miller 
Signed-off-by: Andi Kleen

ipv6: add special mode forwarding=2 to send RS while

2011-08-01T20:55:04+00:00

[ upstream commit c3bccac2fa76f1619dfe4fb7b9bee69de7f066d8 ]
 configured as router

Similar to accepting router advertisement, the IPv6 stack does not send router
solicitations if forwarding is enabled.

This patch enables this behavior to be overruled by setting forwarding to the
special value 2.

Signed-off-by: Thomas Graf 
Signed-off-by: David S. Miller 
Signed-off-by: Andi Kleen

mac80211: fix TKIP replay vulnerability

2011-08-01T20:55:03+00:00

[ upstream commit 34459512ffa7236c849466e3bd604801389734e1 ]

Unlike CCMP, the presence or absence of the QoS
field doesn't change the encryption, only the
TID is used. When no QoS field is present, zero
is used as the TID value. This means that it is
possible for an attacker to take a QoS packet
with TID 0 and replay it as a non-QoS packet.

Unfortunately, mac80211 uses different IVs for
checking the validity of the packet's TKIP IV
when it checks TID 0 and when it checks non-QoS
packets. This means it is vulnerable to this
replay attack.

To fix this, use the same replay counter for
TID 0 and non-QoS packets by overriding the
rx->queue value to 0 if it is 16 (non-QoS).

This is a minimal fix for now. I caused this
issue in

commit 1411f9b531f0a910cd1c85a337737c1e6ffbae6a
Author: Johannes Berg 
Date:   Thu Jul 10 10:11:02 2008 +0200

    mac80211: fix RX sequence number check

while fixing a sequence number issue (there,
a separate counter needs to be used).

[AK: This was a non trivial backport. Johannes, John,
please double check]

Cc: stable@kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Andi Kleen

SUNRPC: Fix a race between work-queue and rpc_killall_tasks

2011-08-01T20:55:02+00:00

[ upstream commit b55c59892e1f3b6c7d4b9ccffb4263e1486fb990 ]

Since rpc_killall_tasks may modify the rpc_task's tk_action field
without any locking, we need to be careful when dereferencing it.

Reported-by: Ben Greear 
Tested-by: Ben Greear 
Signed-off-by: Trond Myklebust 
Cc: stable@kernel.org
Signed-off-by: Andi Kleen

mac80211: Restart STA timers only on associated state

2011-08-01T20:55:02+00:00

[ upstream commit 676b58c27475a9defccc025fea1cbd2b141ee539 ]

A panic was observed when the device is failed to resume properly,
and there are no running interfaces. ieee80211_reconfig tries
to restart STA timers on unassociated state.

Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan 
Signed-off-by: John W. Linville 
Signed-off-by: Andi Kleen

SUNRPC: Fix use of static variable in rpcb_getport_async

2011-08-01T20:55:02+00:00

[ upstream commit ec0dd267bf7d08cb30e321e45a75fd40edd7e528 ]

Because struct rpcbind_args *map was declared static, if two
threads entered this method at the same time, the values
assigned to map could be sent two two differen tasks.
This could cause all sorts of problems, include use-after-free
and double-free of memory.

Fix this by removing the static declaration so that the map
pointer is on the stack.

Signed-off-by: Ben Greear 
Cc: stable@kernel.org
Signed-off-by: Trond Myklebust 
Signed-off-by: Andi Kleen

svcrpc: fix list-corrupting race on nfsd shutdown

2011-08-01T20:55:02+00:00

[ upstream commit ebc63e531cc6a457595dd110b07ac530eae788c3 ]

After commit 3262c816a3d7fb1eaabce633caa317887ed549ae "[PATCH] knfsd:
split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no
longer removed its xpt_ready (then sk_ready) field from whatever list it
was on, noting that there was no point since the whole list was about to
be destroyed anyway.

That was mostly true, but forgot that a few svc_xprt_enqueue()'s might
still be hanging around playing with the about-to-be-destroyed list, and
could get themselves into trouble writing to freed memory if we left
this xprt on the list after freeing it.

(This is actually functionally identical to a patch made first by Ben
Greear, but with more comments.)

Cc: stable@kernel.org
Cc: gnb@fmeh.org
Reported-by: Ben Greear 
Tested-by: Ben Greear 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Andi Kleen

udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet

2011-08-01T20:54:59+00:00

[ Upstream commit 9cfaa8def1c795a512bc04f2aec333b03724ca2e ]

Consider this scenario: When the size of the first received udp packet
is bigger than the receive buffer, MSG_TRUNC bit is set in msg->msg_flags.
However, if checksum error happens and this is a blocking socket, it will
goto try_again loop to receive the next packet.  But if the size of the
next udp packet is smaller than receive buffer, MSG_TRUNC flag should not
be set, but because MSG_TRUNC bit is not cleared in msg->msg_flags before
receive the next packet, MSG_TRUNC is still set, which is wrong.

Fix this problem by clearing MSG_TRUNC flag when starting over for a
new packet.

Signed-off-by: Xufeng Zhang 
Signed-off-by: Paul Gortmaker 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen

ipv6/udp: Use the correct variable to determine non-blocking condition

2011-08-01T20:54:59+00:00

[ Upstream commit 32c90254ed4a0c698caa0794ebb4de63fcc69631 ]

udpv6_recvmsg() function is not using the correct variable to determine
whether or not the socket is in non-blocking operation, this will lead
to unexpected behavior when a UDP checksum error occurs.

Consider a non-blocking udp receive scenario: when udpv6_recvmsg() is
called by sock_common_recvmsg(), MSG_DONTWAIT bit of flags variable in
udpv6_recvmsg() is cleared by "flags & ~MSG_DONTWAIT" in this call:

    err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT,
                   flags & ~MSG_DONTWAIT, &addr_len);

i.e. with udpv6_recvmsg() getting these values:

	int noblock = flags & MSG_DONTWAIT
	int flags = flags & ~MSG_DONTWAIT

So, when udp checksum error occurs, the execution will go to
csum_copy_err, and then the problem happens:

    csum_copy_err:
            ...............
            if (flags & MSG_DONTWAIT)
                    return -EAGAIN;
            goto try_again;
            ...............

But it will always go to try_again as MSG_DONTWAIT has been cleared
from flags at call time -- only noblock contains the original value
of MSG_DONTWAIT, so the test should be:

            if (noblock)
                    return -EAGAIN;

This is also consistent with what the ipv4/udp code does.

Signed-off-by: Xufeng Zhang 
Signed-off-by: Paul Gortmaker 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen