kernel/git/stable/linux.git/net, branch linux-2.6.39.y

bridge: send proper message_age in config BPDU

2011-08-03T19:42:49+00:00

commit 0c03150e7ea8f7fcd03cfef29385e0010b22ee92 upstream. A bridge topology with three systems: +------+ +------+ | A(2) |--| B(1) | +------+ +------+ \ / +------+ | C(3) | +------+ What is supposed to happen: * bridge with the lowest ID is elected root (for example: B) * C detects that A->C is higher cost path and puts in blocking state What happens. Bridge with lowest id (B) is elected correctly as root and things start out fine initially. But then config BPDU doesn't get transmitted from A -> C. Because of that the link from A-C is transistioned to the forwarding state. The root cause of this is that the configuration messages is generated with bogus message age, and dropped before sending. In the standardmessage_age is supposed to be: the time since the generation of the Configuration BPDU by the Root that instigated the generation of this Configuration BPDU. Reimplement this by recording the timestamp (age + jiffies) when recording config information. The old code incorrectly used the time elapsed on the ageing timer which was incorrect. See also: https://bugzilla.vyatta.com/show_bug.cgi?id=7164 Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

SUNRPC: Fix use of static variable in rpcb_getport_async

2011-08-03T19:42:35+00:00

commit ec0dd267bf7d08cb30e321e45a75fd40edd7e528 upstream. 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 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

SUNRPC: Fix a race between work-queue and rpc_killall_tasks

2011-08-03T19:42:34+00:00

commit b55c59892e1f3b6c7d4b9ccffb4263e1486fb990 upstream. 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 Signed-off-by: Greg Kroah-Hartman

mac80211: fix TKIP replay vulnerability

2011-08-03T19:42:33+00:00

commit 34459512ffa7236c849466e3bd604801389734e1 upstream. 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). Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

IPVS netns exit causes crash in conntrack

2011-07-09T06:15:41+00:00

commit 8f4e0a18682d91abfad72ede3d3cb5f3ebdf54b4 upstream. Quote from Patric Mc Hardy "This looks like nfnetlink.c excited and destroyed the nfnl socket, but ip_vs was still holding a reference to a conntrack. When the conntrack got destroyed it created a ctnetlink event, causing an oops in netlink_has_listeners when trying to use the destroyed nfnetlink socket." If nf_conntrack_netlink is loaded before ip_vs this is not a problem. This patch simply avoids calling ip_vs_conn_drop_conntrack() when netns is dying as suggested by Julian. Signed-off-by: Hans Schillstrom Signed-off-by: Simon Horman Signed-off-by: Greg Kroah-Hartman

xfrm: Fix off by one in the replay advance functions

2011-07-09T06:15:39+00:00

[ Upstream commit e756682c8baa47da1648c0c016e9f48ed66bc32d ] We may write 4 byte too much when we reinitialize the anti replay window in the replay advance functions. This patch fixes this by adjusting the last index of the initialization loop. Signed-off-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

vlan: fix typo in vlan_dev_hard_start_xmit()

2011-07-09T06:15:39+00:00

[ Upstream commit 307f73df2b9829ee5a261d1ed432ff683c426cdf ] commit 4af429d29b341bb1735f04c2fb960178ed5d52e7 (vlan: lockless transmit path) have a typo in vlan_dev_hard_start_xmit(), using u64_stats_update_begin() to end the stat update, it should be u64_stats_update_end(). Signed-off-by: Wei Yongjun Reviewed-by: WANG Cong Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

netfilter: Fix ip_route_me_harder triggering ip_rt_bug

2011-07-09T06:15:38+00:00

[ Upstream commit ed6e4ef836d425bc35e33bf20fcec95e68203afa ] Avoid creating input routes with ip_route_me_harder. It does not work for locally generated packets. Instead, restrict sockets to provide valid saddr for output route (or unicast saddr for transparent proxy). For other traffic allow saddr to be unicast or local but if callers forget to check saddr type use 0 for the output route. The resulting handling should be: - REJECT TCP: - in INPUT we can provide addr_type = RTN_LOCAL but better allow rejecting traffic delivered with local route (no IP address => use RTN_UNSPEC to allow also RTN_UNICAST). - FORWARD: RTN_UNSPEC => allow RTN_LOCAL/RTN_UNICAST saddr, add fix to ignore RTN_BROADCAST and RTN_MULTICAST - OUTPUT: RTN_UNSPEC - NAT, mangle, ip_queue, nf_ip_reroute: RTN_UNSPEC in LOCAL_OUT - IPVS: - use RTN_LOCAL in LOCAL_OUT and FORWARD after SNAT to restrict saddr to be local Signed-off-by: Julian Anastasov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ipv4: fix multicast losses

2011-07-09T06:15:38+00:00

[ Upstream commit 9aa3c94ce59066f545521033007abb6441706068 ] Knut Tidemann found that first packet of a multicast flow was not correctly received, and bisected the regression to commit b23dd4fe42b4 (Make output route lookup return rtable directly.) Special thanks to Knut, who provided a very nice bug report, including sample programs to demonstrate the bug. Reported-and-bisectedby: Knut Tidemann Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

NLM: Don't hang forever on NLM unlock requests

2011-07-09T06:15:35+00:00

commit 0b760113a3a155269a3fba93a409c640031dd68f upstream. If the NLM daemon is killed on the NFS server, we can currently end up hanging forever on an 'unlock' request, instead of aborting. Basically, if the rpcbind request fails, or the server keeps returning garbage, we really want to quit instead of retrying. Tested-by: Vasily Averin Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman