linux/net, branch v2.6.34.3

mac80211: avoid scheduling while atomic in mesh_rx_plink_frame

2010-08-10T17:54:13Z

commit c937019761a758f2749b1f3a032b7a91fb044753 upstream. While mesh_rx_plink_frame holds sta->lock... mesh_rx_plink_frame -> mesh_plink_inc_estab_count -> ieee80211_bss_info_change_notify ...but ieee80211_bss_info_change_notify is allowed to sleep. A driver taking advantage of that allowance can cause a scheduling while atomic bug. Similar paths exist for mesh_plink_dec_estab_count, so work around those as well. http://bugzilla.kernel.org/show_bug.cgi?id=16099 Also, correct a minor kerneldoc comment error (mismatched function names). Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

cfg80211: don't get expired BSSes

2010-08-10T17:54:12Z

commit ccb6c1360f8dd43303c659db718e7e0b24175db5 upstream. When kernel-internal users use cfg80211_get_bss() to get a reference to a BSS struct, they may end up getting one that would have been removed from the list if there had been any userspace access to the list. This leads to inconsistencies and problems. Fix it by making cfg80211_get_bss() ignore BSSes that cfg80211_bss_expire() would remove. Fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2180 Reported-by: Jiajia Zheng Tested-by: Jiajia Zheng Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

cfg80211: ignore spurious deauth

2010-08-10T17:54:12Z

commit 643f82e32f14faf0d0944c804203a6681b6b0a1e upstream. Ever since mac80211/drivers are no longer fully in charge of keeping track of the auth status, trying to make them do so will fail. Instead of warning and reporting the deauthentication to userspace, cfg80211 must simply ignore it so that spurious deauthentications, e.g. before starting authentication, aren't seen by userspace as actual deauthentications. Reported-by: Paul Stewart Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

9p: strlen() doesn't count the terminator

2010-08-10T17:54:09Z

commit 5c4bfa17f3ec46becec4b23d12323f7605ebd696 upstream. This is an off by one bug because strlen() doesn't count the NULL terminator. We strcpy() addr into a fixed length array of size UNIX_PATH_MAX later on. The addr variable is the name of the device being mounted. Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

mac80211: fix supported rates IE if AP doesn't give us it's rates

2010-08-02T17:30:16Z

commit 76f273640134f3eb8257179cd5b3bc6ba5fe4a96 upstream. If AP do not provide us supported rates before assiociation, send all rates we are supporting instead of empty information element. v1 -> v2: Add comment. Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ethtool: Fix potential user buffer overflow for ETHTOOL_{G, S}RXFH

2010-08-02T17:30:05Z

commit bf988435bd5b53529f4408a8efb1f433f6ddfda9 upstream. struct ethtool_rxnfc was originally defined in 2.6.27 for the ETHTOOL_{G,S}RXFH command with only the cmd, flow_type and data fields. It was then extended in 2.6.30 to support various additional commands. These commands should have been defined to use a new structure, but it is too late to change that now. Since user-space may still be using the old structure definition for the ETHTOOL_{G,S}RXFH commands, and since they do not need the additional fields, only copy the originally defined fields to and from user-space. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ethtool: Fix potential kernel buffer overflow in ETHTOOL_GRXCLSRLALL

2010-08-02T17:29:49Z

commit db048b69037e7fa6a7d9e95a1271a50dc08ae233 upstream. On a 32-bit machine, info.rule_cnt >= 0x40000000 leads to integer overflow and the buffer may be smaller than needed. Since ETHTOOL_GRXCLSRLALL is unprivileged, this can presumably be used for at least denial of service. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

netfilter: ip6t_REJECT: fix a dst leak in ipv6 REJECT

2010-08-02T17:29:41Z

commit 499031ac8a3df6738f6186ded9da853e8ea18253 upstream. We should release dst if dst->error is set. Bug introduced in 2.6.14 by commit e104411b82f5c ([XFRM]: Always release dst_entry on error in xfrm_lookup) Signed-off-by: Eric Dumazet Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman

ipv6: fix NULL reference in proxy neighbor discovery

2010-08-02T17:29:41Z

commit 9f888160bdcccf0565dd2774956b8d9456e610be upstream. The addition of TLLAO option created a kernel OOPS regression for the case where neighbor advertisement is being sent via proxy path. When using proxy, ipv6_get_ifaddr() returns NULL causing the NULL dereference. Change causing the bug was: commit f7734fdf61ec6bb848e0bafc1fb8bad2c124bb50 Author: Octavian Purdila Date: Fri Oct 2 11:39:15 2009 +0000 make TLLAO option for NA packets configurable Signed-off-by: Stephen Hemminger Acked-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ipvs: Add missing locking during connection table hashing and unhashing

2010-08-02T17:29:41Z

commit aea9d711f3d68c656ad31ab578ecfb0bb5cd7f97 upstream. The code that hashes and unhashes connections from the connection table is missing locking of the connection being modified, which opens up a race condition and results in memory corruption when this race condition is hit. Here is what happens in pretty verbose form: CPU 0 CPU 1 ------------ ------------ An active connection is terminated and we schedule ip_vs_conn_expire() on this CPU to expire this connection. IRQ assignment is changed to this CPU, but the expire timer stays scheduled on the other CPU. New connection from same ip:port comes in right before the timer expires, we find the inactive connection in our connection table and get a reference to it. We proper lock the connection in tcp_state_transition() and read the connection flags in set_tcp_state(). ip_vs_conn_expire() gets called, we unhash the connection from our connection table and remove the hashed flag in ip_vs_conn_unhash(), without proper locking! While still holding proper locks we write the connection flags in set_tcp_state() and this sets the hashed flag again. ip_vs_conn_expire() fails to expire the connection, because the other CPU has incremented the reference count. We try to re-insert the connection into our connection table, but this fails in ip_vs_conn_hash(), because the hashed flag has been set by the other CPU. We re-schedule execution of ip_vs_conn_expire(). Now this connection has the hashed flag set, but isn't actually hashed in our connection table and has a dangling list_head. We drop the reference we held on the connection and schedule the expire timer for timeouting the connection on this CPU. Further packets won't be able to find this connection in our connection table. ip_vs_conn_expire() gets called again, we think it's already hashed, but the list_head is dangling and while removing the connection from our connection table we write to the memory location where this list_head points to. The result will probably be a kernel oops at some other point in time. This race condition is pretty subtle, but it can be triggered remotely. It needs the IRQ assignment change or another circumstance where packets coming from the same ip:port for the same service are being processed on different CPUs. And it involves hitting the exact time at which ip_vs_conn_expire() gets called. It can be avoided by making sure that all packets from one connection are always processed on the same CPU and can be made harder to exploit by changing the connection timeouts to some custom values. Signed-off-by: Sven Wegener Acked-by: Simon Horman Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman