linux/net, branch v2.6.38.6

can: add missing socket check in can/raw release

2011-05-09T22:06:50Z

commit 10022a6c66e199d8f61d9044543f38785713cbbd upstream. v2: added space after 'if' according code style. We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly. Thanks to Dave Jones pointing at this issue in net/can/bcm.c Signed-off-by: Oliver Hartkopp Signed-off-by: David S. Miller Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

can: Add missing socket check in can/bcm release.

2011-05-09T22:06:48Z

commit c6914a6f261aca0c9f715f883a353ae7ff51fe83 upstream. We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly. Signed-off-by: Dave Jones Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

af_unix: Only allow recv on connected seqpacket sockets.

2011-05-09T22:06:46Z

commit a05d2ad1c1f391c7f514a1d1e09b5417968a7d07 upstream. This fixes the following oops discovered by Dan Aloni: > Anyway, the following is the output of the Oops that I got on the > Ubuntu kernel on which I first detected the problem > (2.6.37-12-generic). The Oops that followed will be more useful, I > guess. >[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference > at (null) > [ 5594.681606] IP: [] unix_dgram_recvmsg+0x1fb/0x420 > [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0 > [ 5594.693720] Oops: 0002 [#1] SMP > [ 5594.699888] last sysfs file: The bug was that unix domain sockets use a pseduo packet for connecting and accept uses that psudo packet to get the socket. In the buggy seqpacket case we were allowing unconnected sockets to call recvmsg and try to receive the pseudo packet. That is always wrong and as of commit 7361c36c5 the pseudo packet had become enough different from a normal packet that the kernel started oopsing. Do for seqpacket_recv what was done for seqpacket_send in 2.5 and only allow it on connected seqpacket sockets. Tested-by: Dan Aloni Signed-off-by: Eric W. Biederman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

mac80211: fix SMPS debugfs locking

2011-05-09T22:06:46Z

commit 243e6df4ed919880d079d717641ad699c6530a03 upstream. The locking with SMPS requests means that the debugs file should lock the mgd mutex, not the iflist mutex. Calls to __ieee80211_request_smps() need to hold that mutex, so add an assertion. This has always been wrong, but for some reason never been noticed, probably because the locking error only happens while unassociated. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ip: ip_options_compile() resilient to NULL skb route

2011-04-21T21:33:00Z

commit c65353daf137dd41f3ede3baf62d561fca076228 upstream. Scot Doyle demonstrated ip_options_compile() could be called with an skb without an attached route, using a setup involving a bridge, netfilter, and forged IP packets. Let's make ip_options_compile() and ip_options_rcv_srr() a bit more robust, instead of changing bridge/netfilter code. With help from Hiroaki SHIMODA. Reported-by: Scot Doyle Tested-by: Scot Doyle Signed-off-by: Eric Dumazet Cc: Stephen Hemminger Acked-by: Hiroaki SHIMODA Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bridge: reset IPCB in br_parse_ip_options

2011-04-21T21:33:00Z

commit f8e9881c2aef1e982e5abc25c046820cd0b7cf64 upstream. Commit 462fb2af9788a82 (bridge : Sanitize skb before it enters the IP stack), missed one IPCB init before calling ip_options_compile() Thanks to Scot Doyle for his tests and bug reports. Reported-by: Scot Doyle Signed-off-by: Eric Dumazet Cc: Hiroaki SHIMODA Acked-by: Bandan Das Acked-by: Stephen Hemminger Cc: Jan Lübbe Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix HCI_RESET command synchronization

2011-04-21T21:32:59Z

commit f630cf0d5434e3923e1b8226ffa2753ead6b0ce5 upstream. We can't send new commands before a cmd_complete for the HCI_RESET command shows up. Reported-by: Mikko Vinni Reported-by: Justin P. Mattock Reported-by: Ed Tomlinson Signed-off-by: Gustavo F. Padovan Tested-by: Justin P. Mattock Tested-by: Mikko Vinni Tested-by: Ed Tomlinson

bridge: Reset IPCB when entering IP stack on NF_FORWARD

2011-04-21T21:32:37Z

[ Upstream commit 6b1e960fdbd75dcd9bcc3ba5ff8898ff1ad30b6e ] Whenever we enter the IP stack proper from bridge netfilter we need to ensure that the skb is in a form the IP stack expects it to be in. The entry point on NF_FORWARD did not meet the requirements of the IP stack, therefore leading to potential crashes/panics. This patch fixes the problem. Signed-off-by: Herbert Xu Acked-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

vlan: should take into account needed_headroom

2011-04-21T21:32:36Z

[ Upstream commit d870bfb9d366c5d466c0f5419a4ec95a3f71ea8a ] Commit c95b819ad7 (gre: Use needed_headroom) made gre use needed_headroom instead of hard_header_len This uncover a bug in vlan code. We should make sure vlan devices take into account their real_dev->needed_headroom or we risk a crash in ipgre_header(), because we dont have enough room to push IP header in skb. Reported-by: Diddi Oscarsson Signed-off-by: Eric Dumazet Cc: Patrick McHardy Cc: Herbert Xu Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

xfrm: Refcount destination entry on xfrm_lookup

2011-04-21T21:32:34Z

[ Upstream commit fbd5060875d25f7764fd1c3d35b83a8ed1d88d7b ] We return a destination entry without refcount if a socket policy is found in xfrm_lookup. This triggers a warning on a negative refcount when freeeing this dst entry. So take a refcount in this case to fix it. This refcount was forgotten when xfrm changed to cache bundles instead of policies for outgoing flows. Signed-off-by: Steffen Klassert Acked-by: Timo Teräs Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman