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

net: Fix soft lockups/OOM issues w/ unix garbage collector (CVE-2008-5300)

2008-12-05T18:55:25+00:00

commit 5f23b734963ec7eaa3ebcd9050da0c9b7d143dd3 upstream.

This is an implementation of David Miller's suggested fix in:
  https://bugzilla.redhat.com/show_bug.cgi?id=470201

It has been updated to use wait_event() instead of
wait_event_interruptible().

Paraphrasing the description from the above report, it makes sendmsg()
block while UNIX garbage collection is in progress. This avoids a
situation where child processes continue to queue new FDs over a
AF_UNIX socket to a parent which is in the exit path and running
garbage collection on these FDs. This contention can result in soft
lockups and oom-killing of unrelated processes.

Signed-off-by: dann frazier 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: fix /proc/net/snmp as memory corruptor

2008-11-20T22:54:48+00:00

commit b971e7ac834e9f4bda96d5a96ae9abccd01c1dd8 upstream.

icmpmsg_put() can happily corrupt kernel memory, using a static
table and forgetting to reset an array index in a loop.

Remove the static array since its not safe without proper locking.

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

net: unix: fix inflight counting bug in garbage collector

2008-11-13T17:55:58+00:00

commit 6209344f5a3795d34b7f2c0061f49802283b6bdd upstream

Previously I assumed that the receive queues of candidates don't
change during the GC.  This is only half true, nothing can be received
from the queues (see comment in unix_gc()), but buffers could be added
through the other half of the socket pair, which may still have file
descriptors referring to it.

This can result in inc_inflight_move_tail() erronously increasing the
"inflight" counter for a unix socket for which dec_inflight() wasn't
previously called.  This in turn can trigger the "BUG_ON(total_refs <
inflight_refs)" in a later garbage collection run.

Fix this by only manipulating the "inflight" counter for sockets which
are candidates themselves.  Duplicating the file references in
unix_attach_fds() is also needed to prevent a socket becoming a
candidate for GC while the skb that contains it is not yet queued.

Reported-by: Andrea Bittau 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

net: Fix recursive descent in __scm_destroy().

2008-11-07T17:55:19+00:00

commit f8d570a4745835f2238a33b537218a1bb03fc671 and
3b53fbf4314594fa04544b02b2fc6e607912da18 upstream (because once wasn't
good enough...)

__scm_destroy() walks the list of file descriptors in the scm_fp_list
pointed to by the scm_cookie argument.

Those, in turn, can close sockets and invoke __scm_destroy() again.

There is nothing which limits how deeply this can occur.

The idea for how to fix this is from Linus.  Basically, we do all of
the fput()s at the top level by collecting all of the scm_fp_list
objects hit by an fput().  Inside of the initial __scm_destroy() we
keep running the list until it is empty.

Signed-off-by: David S. Miller 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

pkt_sched: sch_generic: Fix oops in sch_teql

2008-11-07T03:05:41+00:00

[ Upstream commit 9f3ffae0dbce491a3e9871b686342fd5aa854f05 ]

After these commands:
# modprobe sch_teql
# tc qdisc add dev eth0 root teql0
# tc qdisc del dev eth0 root
we get an oops in teql_destroy() when spin_lock is taken from a null
qdisc_sleeping pointer. It's because at the moment teql0 dev haven't
been activated yet, and a qdisc_root_sleeping() is pointing to noop
qdisc's netdev_queue with qdisc_sleeping uninitialized. This patch
fixes this both for noop and noqueue netdev_queues to avoid similar
problems in the future.

Signed-off-by: Jarek Poplawski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcpv6: fix option space offsets with md5

2008-11-07T03:05:41+00:00

[ Upstream commit 53b125779fb0b29e5b316bf3dc7d199e6dcea567 ]

More breakage :-), part of timestamps just were previously
overwritten.

Signed-off-by: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: Restore ordering of TCP options for the sake of inter-operability

2008-11-07T03:05:41+00:00

[ Upstream commit fd6149d332973bafa50f03ddb0ea9513e67f4517 ]

This is not our bug! Sadly some devices cannot cope with the change
of TCP option ordering which was a result of the recent rewrite of
the option code (not that there was some particular reason steming
from the rewrite for the reordering) though any ordering of TCP
options is perfectly legal. Thus we restore the original ordering
to allow interoperability with/through such broken devices and add
some warning about this trap. Since the reordering just happened
without any particular reason, this change shouldn't cost us
anything.

There are already couple of known failure reports (within close
proximity of the last release), so the problem might be more
wide-spread than a single device. And other reports which may
be due to the same problem though the symptoms were less obvious.
Analysis of one of the case revealed (with very high probability)
that sack capability cannot be negotiated as the first option
(SYN never got a response).

Signed-off-by: Ilpo Järvinen 
Reported-by: Aldo Maggi 
Tested-by: Aldo Maggi 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

syncookies: fix inclusion of tcp options in syn-ack

2008-11-07T03:05:41+00:00

[ Upstream commit 8b5f12d04b2e93842f3dda01f029842047bf3f81 ]

David Miller noticed that commit
33ad798c924b4a1afad3593f2796d465040aadd5 '(tcp: options clean up')
did not move the req->cookie_ts check.
This essentially disabled commit 4dfc2817025965a2fc78a18c50f540736a6b5c24
'[Syncookies]: Add support for TCP options via timestamps.'.

This restores the original logic.

Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netfilter: restore lost ifdef guarding defrag exception

2008-10-25T21:32:41+00:00

netfilter: restore lost #ifdef guarding defrag exception

Upstream commit 38f7ac3eb:

Nir Tzachar  reported a warning when sending
fragments over loopback with NAT:

[ 6658.338121] WARNING: at net/ipv4/netfilter/nf_nat_standalone.c:89 nf_nat_fn+0x33/0x155()

The reason is that defragmentation is skipped for already tracked connections.
This is wrong in combination with NAT and ip_conntrack actually had some ifdefs
to avoid this behaviour when NAT is compiled in.

The entire "optimization" may seem a bit silly, for now simply restoring the
lost #ifdef is the easiest solution until we can come up with something better.

Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

netfilter: snmp nat leaks memory in case of failure

2008-10-25T21:32:41+00:00

netfilter: snmp nat leaks memory in case of failure

Upstream commit 311670f3e:

Signed-off-by: Ilpo Jarvinen 
Signed-off-by: Patrick McHardy