linux/net, branch v3.10.8

nl80211: fix another nl80211_fam.attrbuf race

2013-08-20T15:43:04Z

commit c319d50bfcf678c2857038276d9fab3c6646f3bf upstream. This is similar to the race Linus had reported, but in this case it's an older bug: nl80211_prepare_wdev_dump() uses the wiphy index in cb->args[0] as it is and thus parses the message over and over again instead of just once because 0 is the first valid wiphy index. Similar code in nl80211_testmode_dump() correctly offsets the wiphy_index by 1, do that here as well. Reported-by: Ben Hutchings Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

cfg80211: fix P2P GO interface teardown

2013-08-20T15:43:03Z

commit 74418edec915d0f446debebde08d170c7b8ba0ee upstream. When a P2P GO interface goes down, cfg80211 doesn't properly tear it down, leading to warnings later. Add the GO interface type to the enumeration to tear it down like AP interfaces. Otherwise, we leave it pending and mac80211's state can get very confused, leading to warnings later. Reported-by: Ilan Peer Tested-by: Ilan Peer Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

genetlink: fix family dump race

2013-08-20T15:43:03Z

commit 58ad436fcf49810aa006016107f494c9ac9013db upstream. When dumping generic netlink families, only the first dump call is locked with genl_lock(), which protects the list of families, and thus subsequent calls can access the data without locking, racing against family addition/removal. This can cause a crash. Fix it - the locking needs to be conditional because the first time around it's already locked. A similar bug was reported to me on an old kernel (3.4.47) but the exact scenario that happened there is no longer possible, on those kernels the first round wasn't locked either. Looking at the current code I found the race described above, which had also existed on the old kernel. Reported-by: Andrei Otcheretianski Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

mac80211: continue using disabled channels while connected

2013-08-20T15:43:03Z

commit ddfe49b42d8ad4bfdf92d63d4a74f162660d878d upstream. In case the AP has different regulatory information than we do, it can happen that we connect to an AP based on e.g. the world roaming regulatory data, and then update our database with the AP's country information disables the channel the AP is using. If this happens on an HT AP, the bandwidth tracking code will hit the WARN_ON() and disconnect. Since that's not very useful, ignore the channel-disable flag in bandwidth tracking. Reported-by: Chris Wright Tested-by: Chris Wright Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: fix infinite loop in ieee80211_determine_chantype

2013-08-20T15:43:03Z

commit b56e4b857c5210e848bfb80e074e5756a36cd523 upstream. Commit "3d9646d mac80211: fix channel selection bug" introduced a possible infinite loop by moving the out target above the chandef_downgrade while loop. When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump back up to re-run the while loop...indefinitely. Replace goto with break and carry on. This may not be sufficient to connect to the AP, but will at least keep the cpu from livelocking. Thanks to Derek Atkins as an extra pair of debugging eyes. Signed-off-by: Chris Wright Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: ignore HT primary channel while connected

2013-08-20T15:43:03Z

commit 5cdaed1e878d723d56d04ae0be1738124acf9f46 upstream. While we're connected, the AP shouldn't change the primary channel in the HT information. We checked this, and dropped the connection if it did change it. Unfortunately, this is causing problems on some APs, e.g. on the Netgear WRT610NL: the beacons seem to always contain a bad channel and if we made a connection using a probe response (correct data) we drop the connection immediately and can basically not connect properly at all. Work around this by ignoring the HT primary channel information in beacons if we're already connected. Also print out more verbose messages in the other situations to help diagnose similar bugs quicker in the future. Acked-by: Andy Isaacson Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

SUNRPC: If the rpcbind channel is disconnected, fail the call to unregister

2013-08-15T05:59:08Z

commit 786615bc1ce84150ded80daea6bd9f6297f48e73 upstream. If rpcbind causes our connection to the AF_LOCAL socket to close after we've registered a service, then we want to be careful about reconnecting since the mount namespace may have changed. By simply refusing to reconnect the AF_LOCAL socket in the case of unregister, we avoid the need to somehow save the mount namespace. While this may lead to some services not unregistering properly, it should be safe. Signed-off-by: Trond Myklebust Cc: Nix Cc: Jeff Layton Signed-off-by: Greg Kroah-Hartman

SUNRPC: Don't auto-disconnect from the local rpcbind socket

2013-08-15T05:59:08Z

commit 00326ed6442c66021cd4b5e19e80f3e2027d5d42 upstream. There is no need for the kernel to time out the AF_LOCAL connection to the rpcbind socket, and doing so is problematic because when it is time to reconnect, our process may no longer be using the same mount namespace. Reported-by: Nix Signed-off-by: Trond Myklebust Cc: Jeff Layton Signed-off-by: Greg Kroah-Hartman

net_sched: info leak in atm_tc_dump_class()

2013-08-12T01:35:26Z

[ Upstream commit 8cb3b9c3642c0263d48f31d525bcee7170eedc20 ] The "pvc" struct has a hole after pvc.sap_family which is not cleared. Signed-off-by: Dan Carpenter Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

af_key: more info leaks in pfkey messages

2013-08-12T01:35:25Z

[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ] This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify messages". There are some struct members which don't get initialized and could disclose small amounts of private information. Acked-by: Mathias Krause Signed-off-by: Dan Carpenter Acked-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman