linux/net, branch v3.10.22

cfg80211: fix scheduled scan pointer access

2013-12-04T18:57:30Z

commit 79845c662eeb95c9a180b9bd0d3ad848ee65b94c upstream. Since rdev->sched_scan_req is dereferenced outside the lock protecting it, this might be done at the wrong time, causing crashes. Move the dereference to where it should be - inside the RTNL locked section. Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

9p: send uevent after adding/removing mount_tag attribute

2013-12-04T18:57:19Z

commit e0d6cb9cd3a3ac8a3b8e5b22b83c4f8619786f22 upstream. This driver adds an attribute to the existing virtio device so a CHANGE event is required in order udev rules to make use of it. The ADD event happens before this driver is probed and unlike a more typical driver like a block device there isn't a higher level device to watch for. Signed-off-by: Michael Marineau Signed-off-by: Eric Van Hensbergen Signed-off-by: Greg Kroah-Hartman

SUNRPC: Fix a data corruption issue when retransmitting RPC calls

2013-11-29T19:11:52Z

commit a6b31d18b02ff9d7915c5898c9b5ca41a798cd73 upstream. The following scenario can cause silent data corruption when doing NFS writes. It has mainly been observed when doing database writes using O_DIRECT. 1) The RPC client uses sendpage() to do zero-copy of the page data. 2) Due to networking issues, the reply from the server is delayed, and so the RPC client times out. 3) The client issues a second sendpage of the page data as part of an RPC call retransmission. 4) The reply to the first transmission arrives from the server _before_ the client hardware has emptied the TCP socket send buffer. 5) After processing the reply, the RPC state machine rules that the call to be done, and triggers the completion callbacks. 6) The application notices the RPC call is done, and reuses the pages to store something else (e.g. a new write). 7) The client NIC drains the TCP socket send buffer. Since the page data has now changed, it reads a corrupted version of the initial RPC call, and puts it on the wire. This patch fixes the problem in the following manner: The ordering guarantees of TCP ensure that when the server sends a reply, then we know that the _first_ transmission has completed. Using zero-copy in that situation is therefore safe. If a time out occurs, we then send the retransmission using sendmsg() (i.e. no zero-copy), We then know that the socket contains a full copy of the data, and so it will retransmit a faithful reproduction even if the RPC call completes, and the application reuses the O_DIRECT buffer in the meantime. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

SUNRPC: don't map EKEYEXPIRED to EACCES in call_refreshresult

2013-11-29T19:11:41Z

commit f1ff0c27fd9987c59d707cd1a6b6c1fc3ae0a250 upstream. The NFS layer needs to know when a key has expired. This change also returns -EKEYEXPIRED to the application, and the informative "Key has expired" error message is displayed. The user then knows that credential renewal is required. Signed-off-by: Andy Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

batman-adv: set up network coding packet handlers during module init

2013-11-20T20:27:47Z

commit 6c519bad7b19a2c14a075b400edabaa630330123 upstream. batman-adv saves its table of packet handlers as a global state, so handlers must be set up only once (and setting them up a second time will fail). The recently-added network coding support tries to set up its handler each time a new softif is registered, which obviously fails when more that one softif is used (and in consequence, the softif creation fails). Fix this by splitting up batadv_nc_init into batadv_nc_init (which is called only once) and batadv_nc_mesh_init (which is called for each softif); in addition batadv_nc_free is renamed to batadv_nc_mesh_free to keep naming consistent. Signed-off-by: Matthias Schiffer Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Cc: David Miller Signed-off-by: Greg Kroah-Hartman

net: flow_dissector: fail on evil iph->ihl

2013-11-20T20:27:46Z

[ Upstream commit 6f092343855a71e03b8d209815d8c45bf3a27fcd ] We don't validate iph->ihl which may lead a dead loop if we meet a IPIP skb whose iph->ihl is zero. Fix this by failing immediately when iph->ihl is evil (less than 5). This issue were introduced by commit ec5efe7946280d1e84603389a1030ccec0a767ae (rps: support IPIP encapsulation). Signed-off-by: Jason Wang Cc: Eric Dumazet Cc: Petr Matousek Cc: Michael S. Tsirkin Cc: Daniel Borkmann Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ipv6: ip6_dst_check needs to check for expired dst_entries

2013-11-20T20:27:46Z

[ Upstream commit e3bc10bd95d7fcc3f2ac690c6ff22833ea6781d6 ] On receiving a packet too big icmp error we check if our current cached dst_entry in the socket is still valid. This validation check did not care about the expiration of the (cached) route. The error path I traced down: The socket receives a packet too big mtu notification. It still has a valid dst_entry and thus issues the ip6_rt_pmtu_update on this dst_entry, setting RTF_EXPIRE and updates the dst.expiration value (which could fail because of not up-to-date expiration values, see previous patch). In some seldom cases we race with a) the ip6_fib gc or b) another routing lookup which would result in a recreation of the cached rt6_info from its parent non-cached rt6_info. While copying the rt6_info we reinitialize the metrics store by copying it over from the parent thus invalidating the just installed pmtu update (both dsts use the same key to the inetpeer storage). The dst_entry with the just invalidated metrics data would just get its RTF_EXPIRES flag cleared and would continue to stay valid for the socket. We should have not issued the pmtu update on the already expired dst_entry in the first placed. By checking the expiration on the dst entry and doing a relookup in case it is out of date we close the race because we would install a new rt6_info into the fib before we issue the pmtu update, thus closing this race. Not reliably updating the dst.expire value was fixed by the patch "ipv6: reset dst.expires value when clearing expire flag". Reported-by: Steinar H. Gunderson Reported-by: Valentijn Sessink Cc: YOSHIFUJI Hideaki Signed-off-by: Hannes Frederic Sowa Reviewed-by: Eric Dumazet Tested-by: Valentijn Sessink Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ip_gre: Fix WCCPv2 header parsing.

2013-11-20T20:27:46Z

[ No applicable upstream commit, the upstream implementation is now completely different and doesn't have this bug. ] In case of WCCPv2 GRE header has extra four bytes. Following patch pull those extra four bytes so that skb offsets are set correctly. CC: Eric Dumazet Reported-by: Peter Schmitt Tested-by: Peter Schmitt Signed-off-by: Pravin B Shelar Signed-off-by: Greg Kroah-Hartman

cfg80211: fix warning when using WEXT for IBSS

2013-11-13T03:05:31Z

commit f478f33a93f9353dcd1fe55445343d76b1c3f84a upstream. Fix kernel warning when using WEXT for configuring ad-hoc mode, e.g. "iwconfig wlan0 essid test channel 1" WARNING: at net/wireless/chan.c:373 cfg80211_chandef_usable+0x50/0x21c [cfg80211]() The warning is caused by an uninitialized variable center_freq1. Signed-off-by: Bruno Randolf Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: fix crash if bitrate calculation goes wrong

2013-11-13T03:05:30Z

commit d86aa4f8ca58898ec6a94c0635da20b948171ed7 upstream. If a frame's timestamp is calculated, and the bitrate calculation goes wrong and returns zero, the system will attempt to divide by zero and crash. Catch this case and print the rate information that the driver reported when this happens. Reported-by: Thomas Lindroth Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman