linux/net, branch v2.6.34.2

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

IPv6: only notify protocols if address is completely gone

2010-08-02T17:29:41Z

(cherry picked from commit 8595805aafc8b077e01804c9a3668e9aa3510e89) The notifier for address down should only be called if address is completely gone, not just being marked as tentative on link transition. The code in net-next would case bonding/sctp/s390 to see address disappear on link down, but they would never see it reappear on link up. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

IPv6: keep route for tentative address

2010-08-02T17:29:40Z

(cherry picked from commit 93fa159abe50d3c55c7f83622d3f5c09b6e06f4b) Recent changes preserve IPv6 address when link goes down (good). But would cause address to point to dead dst entry (bad). The simplest fix is to just not delete route if address is being held for later use. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

mac80211: do not wip out old supported rates

2010-08-02T17:29:31Z

commit f0b058b61711ebf5be94d6865ca7b2c259b71d37 upstream. Use old supported rates, if AP do not provide supported rates information element in a new managment frame. Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

SUNRPC: Fix a re-entrancy bug in xs_tcp_read_calldir()

2010-08-02T17:29:29Z

commit b76ce56192bcf618013fb9aecd83488cffd645cc upstream. If the attempt to read the calldir fails, then instead of storing the read bytes, we currently discard them. This leads to a garbage final result when upon re-entry to the same routine, we read the remaining bytes. Fixes the regression in bugzilla number 16213. Please see https://bugzilla.kernel.org/show_bug.cgi?id=16213 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman