linux-toradex.git/net, branch v2.6.34.11

net: sk_add_backlog() take rmem_alloc into account

2012-03-14T14:58:05+00:00

commit c377411f2494a931ff7facdbb3a6839b1266bcf6 upstream.

Current socket backlog limit is not enough to really stop DDOS attacks,
because user thread spend many time to process a full backlog each
round, and user might crazy spin on socket lock.

We should add backlog size and receive_queue size (aka rmem_alloc) to
pace writers, and let user run without being slow down too much.

Introduce a sk_rcvqueues_full() helper, to avoid taking socket lock in
stress situations.

Under huge stress from a multiqueue/RPS enabled NIC, a single flow udp
receiver can now process ~200.000 pps (instead of ~100 pps before the
patch) on a 8 core machine.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

Bluetooth: Prevent buffer overflow in l2cap config request

2012-03-14T14:58:04+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.

[PG: 34 uses l2cap_pi(sk)->... instead of a local chan->... variable]

Signed-off-by: Dan Rosenberg 
Signed-off-by: Gustavo F. Padovan 
Signed-off-by: Paul Gortmaker

rtnetlink: Add missing manual netlink notification in dev_change_net_namespaces

2012-03-14T14:58:03+00:00

commit d2237d35748e7f448a9c2d9dc6a85ef637466e24 upstream.

Renato Westphal noticed that since commit a2835763e130c343ace5320c20d33c281e7097b7
"rtnetlink: handle rtnl_link netlink notifications manually" was merged
we no longer send a netlink message when a networking device is moved
from one network namespace to another.

Fix this by adding the missing manual notification in dev_change_net_namespaces.

Since all network devices that are processed by dev_change_net_namspaces are
in the initialized state the complicated tests that guard the manual
rtmsg_ifinfo calls in rollback_registered and register_netdevice are
unnecessary and we can just perform a plain notification.

Cc: stable@kernel.org
Tested-by: Renato Westphal 
Signed-off-by: Eric W. Biederman 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

ipv6: udp: fix the wrong headroom check

2012-03-14T14:58:03+00:00

commit a9cf73ea7ff78f52662c8658d93c226effbbedde upstream.

At this point, skb->data points to skb_transport_header.
So, headroom check is wrong.

For some case:bridge(UFO is on) + eth device(UFO is off),
there is no enough headroom for IPv6 frag head.
But headroom check is always false.

This will bring about data be moved to there prior to skb->head,
when adding IPv6 frag header to skb.

Signed-off-by: Shan Wei 
Acked-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

inet_diag: fix inet_diag_bc_audit()

2012-03-14T14:58:02+00:00

commit eeb1497277d6b1a0a34ed36b97e18f2bd7d6de0d upstream.

A malicious user or buggy application can inject code and trigger an
infinite loop in inet_diag_bc_audit()

Also make sure each instruction is aligned on 4 bytes boundary, to avoid
unaligned accesses.

Reported-by: Dan Rosenberg 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

dccp: handle invalid feature options length

2012-03-14T14:57:54+00:00

commit a294865978b701e4d0d90135672749531b9a900d upstream.

A length of zero (after subtracting two for the type and len fields) for
the DCCPO_{CHANGE,CONFIRM}_{L,R} options will cause an underflow due to
the subtraction.  The subsequent code may read past the end of the
options value buffer when parsing.  I'm unsure of what the consequences
of this might be, but it's probably not good.

Signed-off-by: Dan Rosenberg 
Acked-by: Gerrit Renker 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

ipv6: Silence privacy extensions initialization

2012-03-14T14:57:50+00:00

commit 2fdc1c8093255f9da877d7b9ce3f46c2098377dc upstream.

When a network namespace is created (via CLONE_NEWNET), the loopback
interface is automatically added to the new namespace, triggering a
printk in ipv6_add_dev() if CONFIG_IPV6_PRIVACY is set.

This is problematic for applications which use CLONE_NEWNET as
part of a sandbox, like Chromium's suid sandbox or recent versions of
vsftpd. On a busy machine, it can lead to thousands of useless
"lo: Disabled Privacy Extensions" messages appearing in dmesg.

It's easy enough to check the status of privacy extensions via the
use_tempaddr sysctl, so just removing the printk seems like the most
sensible solution.

Signed-off-by: Romain Francoise 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

SUNRPC: fix NFS client over TCP hangs due to packet loss (Bug 16494)

2012-03-14T14:57:36+00:00

commit 669502ff31d7dba1849aec7ee2450a3c61f57d39 upstream.

When reusing a TCP connection, ensure that it's aborted if a previous
shutdown attempt has been made on that connection so that the RPC over
TCP recovery mechanism succeeds.

Signed-off-by: Andy Chittenden 
Signed-off-by: Trond Myklebust 
Signed-off-by: Paul Gortmaker

af_unix: Only allow recv on connected seqpacket sockets.

2012-03-14T14:57:30+00:00

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: Paul Gortmaker

can: add missing socket check in can/raw release

2012-03-14T14:57:20+00:00

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 
Signed-off-by: Paul Gortmaker