linux-stable.git/net, branch linux-2.6.33.y

net_sched: Fix qdisc_notify()

2011-11-07T21:47:41+00:00

commit 53b0f08042f04813cd1a7473dacd3edfacb28eb3 upstream.

Ben Pfaff reported a kernel oops and provided a test program to
reproduce it.

https://kerneltrap.org/mailarchive/linux-netdev/2010/5/21/6277805

tc_fill_qdisc() should not be called for builtin qdisc, or it
dereference a NULL pointer to get device ifindex.

Fix is to always use tc_qdisc_dump_ignore() before calling
tc_fill_qdisc().

Reported-by: Ben Pfaff 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

nl80211: fix overflow in ssid_len

2011-11-07T21:47:40+00:00

commit 57a27e1d6a3bb9ad4efeebd3a8c71156d6207536 upstream.

When one of the SSID's length passed in a scan or sched_scan request
is larger than 255, there will be an overflow in the u8 that is used
to store the length before checking.  This causes the check to fail
and we overrun the buffer when copying the SSID.

Fix this by checking the nl80211 attribute length before copying it to
the struct.

This is a follow up for the previous commit
208c72f4fe44fe09577e7975ba0e7fa0278f3d03, which didn't fix the problem
entirely.

Reported-by: Ido Yariv 
Signed-off-by: Luciano Coelho 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Prevent buffer overflow in l2cap config request

2011-11-07T21:47:40+00:00

commit 7ac28817536797fd40e9646452183606f9e17f71 upstream.

A remote user can provide a small value for the command size field in
the command header of an l2cap configuration request, resulting in an
integer underflow when subtracting the size of the configuration request
header.  This results in copying a very large amount of data via
memcpy() and destroying the kernel heap.  Check for underflow.

Signed-off-by: Dan Rosenberg 
Signed-off-by: Gustavo F. Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.

2011-11-07T21:47:38+00:00

commit 8d03e971cf403305217b8e62db3a2e5ad2d6263f upstream.

Structures "l2cap_conninfo" and "rfcomm_conninfo" have one padding
byte each. This byte in "cinfo" is copied to userspace uninitialized.

Signed-off-by: Filip Palian 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan 
Signed-off-by: Greg Kroah-Hartman

NLM: Don't hang forever on NLM unlock requests

2011-11-07T21:47:37+00:00

commit 0b760113a3a155269a3fba93a409c640031dd68f upstream.

If the NLM daemon is killed on the NFS server, we can currently end up
hanging forever on an 'unlock' request, instead of aborting. Basically,
if the rpcbind request fails, or the server keeps returning garbage, we
really want to quit instead of retrying.

Tested-by: Vasily Averin 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

scm: lower SCM_MAX_FD

2011-11-07T21:47:36+00:00

commit bba14de98753cb6599a2dae0e520714b2153522d upstream.

Lower SCM_MAX_FD from 255 to 253 so that allocations for scm_fp_list are
halved. (commit f8d570a4 added two pointers in this structure)

scm_fp_dup() should not copy whole structure (and trigger kmemcheck
warnings), but only the used part. While we are at it, only allocate
needed size.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

gro: Re-fix different skb headrooms

2011-11-07T21:47:34+00:00

commit 64289c8e6851bca0e589e064c9a5c9fbd6ae5dd4 upstream.

The patch: "gro: fix different skb headrooms" in its part:
"2) allocate a minimal skb for head of frag_list" is buggy. The copied
skb has p->data set at the ip header at the moment, and skb_gro_offset
is the length of ip + tcp headers. So, after the change the length of
mac header is skipped. Later skb_set_mac_header() sets it into the
NET_SKB_PAD area (if it's long enough) and ip header is misaligned at
NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the
original skb was wrongly allocated, so let's copy it as it was.

bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
fixes commit: 3d3be4333fdf6faa080947b331a6a19bce1a4f57

Reported-by: Plamen Petrov 
Signed-off-by: Jarek Poplawski 
CC: Eric Dumazet 
Acked-by: Eric Dumazet 
Tested-by: Plamen Petrov 
Signed-off-by: David S. Miller 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

gro: fix different skb headrooms

2011-11-07T21:47:33+00:00

commit 3d3be4333fdf6faa080947b331a6a19bce1a4f57 upstream.

Packets entering GRO might have different headrooms, even for a given
flow (because of implementation details in drivers, like copybreak).
We cant force drivers to deliver packets with a fixed headroom.

1) fix skb_segment()

skb_segment() makes the false assumption headrooms of fragments are same
than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
errors, and crash later in skb_copy_and_csum_dev()

2) allocate a minimal skb for head of frag_list

skb_gro_receive() uses netdev_alloc_skb(headroom + skb_gro_offset(p)) to
allocate a fresh skb. This adds NET_SKB_PAD to a padding already
provided by netdevice, depending on various things, like copybreak.

Use alloc_skb() to allocate an exact padding, to reduce cache line
needs:
NET_SKB_PAD + NET_IP_ALIGN

bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626

Many thanks to Plamen Petrov, testing many debugging patches !
With help of Jarek Poplawski.

Reported-by: Plamen Petrov 
Signed-off-by: Eric Dumazet 
CC: Jarek Poplawski 
Cc: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: Fix a memmove bug in dev_gro_receive()

2011-11-07T21:47:33+00:00

commit e5093aec2e6b60c3df2420057ffab9ed4a6d2792 upstream.

>Xin Xiaohui wrote:
> I looked into the code dev_gro_receive(), found the code here:
> if the frags[0] is pulled to 0, then the page will be released,
> and memmove() frags left.
> Is that right? I'm not sure if memmove do right or not, but
> frags[0].size is never set after memove at least. what I think
> a simple way is not to do anything if we found frags[0].size == 0.
> The patch is as followed.
...

This version of the patch fixes the bug directly in memmove.

Reported-by: "Xin, Xiaohui" 
Signed-off-by: Jarek Poplawski 
Signed-off-by: David S. Miller 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

x25: Prevent skb overreads when checking call user data

2011-11-07T21:47:09+00:00

commit 7f81e25befdfb3272345a2e775f520e1d515fa20 upstream.

x25_find_listener does not check that the amount of call user data given
in the skb is big enough in per-socket comparisons, hence buffer
overreads may occur.  Fix this by adding a check.

Signed-off-by: Matthew Daley 
Cc: Eric Dumazet 
Cc: Andrew Hendry 
Acked-by: Andrew Hendry 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman