linux-toradex.git/net/ipv4, branch v2.6.35.4

tcp: cookie transactions setsockopt memory leak

2010-08-26T23:45:58+00:00

[ Upstream commit a3bdb549e30e7a263f7a589747c40e9c50110315 ]

There is a bug in do_tcp_setsockopt(net/ipv4/tcp.c),
TCP_COOKIE_TRANSACTIONS case.
In some cases (when tp->cookie_values == NULL) new tcp_cookie_values
structure can be allocated (at cvp), but not bound to
tp->cookie_values. So a memory leak occurs.

Signed-off-by: Dmitry Popov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

arp_notify: allow drivers to explicitly request a notification event.

2010-08-10T18:09:15+00:00

commit 06c4648d46d1b757d6b9591a86810be79818b60c upstream.

Currently such notifications are only generated when the device comes up or the
address changes. However one use case for these notifications is to enable
faster network recovery after a virtual machine migration (by causing switches
to relearn their MAC tables). A migration appears to the network stack as a
temporary loss of carrier and therefore does not trigger either of the current
conditions. Rather than adding carrier up as a trigger (which can cause issues
when interfaces a flapping) simply add an interface which the driver can use
to explicitly trigger the notification.

Signed-off-by: Ian Campbell 
Cc: Stephen Hemminger 
Cc: Jeremy Fitzhardinge 
Cc: David S. Miller 
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: fix crash in tcp_xmit_retransmit_queue

2010-07-19T19:43:49+00:00

It can happen that there are no packets in queue while calling
tcp_xmit_retransmit_queue(). tcp_write_queue_head() then returns
NULL and that gets deref'ed to get sacked into a local var.

There is no work to do if no packets are outstanding so we just
exit early.

This oops was introduced by 08ebd1721ab8fd (tcp: remove tp->lost_out
guard to make joining diff nicer).

Signed-off-by: Ilpo Järvinen 
Reported-by: Lennart Schulte 
Tested-by: Lennart Schulte 
Signed-off-by: David S. Miller

ipmr: Don't leak memory if fib lookup fails.

2010-07-16T05:38:43+00:00

This was detected using two mcast router tables.  The
pimreg for the second interface did not have a specific
mrule, so packets received by it were handled by the
default table, which had nothing configured.

This caused the ipmr_fib_lookup to fail, causing
the memory leak.

Signed-off-by: Ben Greear 
Signed-off-by: David S. Miller

rfs: call sock_rps_record_flow() in tcp_splice_read()

2010-07-14T21:45:15+00:00

rfs: call sock_rps_record_flow() in tcp_splice_read()

call sock_rps_record_flow() in tcp_splice_read(), so the applications using
splice(2) or sendfile(2) can utilize RFS.

Signed-off-by: Changli Gao 
----
 net/ipv4/tcp.c |    1 +
 1 file changed, 1 insertion(+)
Signed-off-by: David S. Miller

xfrm: fix xfrm by MARK logic

2010-07-04T18:46:07+00:00

While using xfrm by MARK feature in
2.6.34 - 2.6.35 kernels, the mark
is always cleared in flowi structure via memset in
_decode_session4 (net/ipv4/xfrm4_policy.c), so
the policy lookup fails.
IPv6 code is affected by this bug too.

Signed-off-by: Peter Kosyh 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

udp: Fix bogus UFO packet generation

2010-06-21T20:57:34+00:00

It has been reported that the new UFO software fallback path
fails under certain conditions with NFS.  I tracked the problem
down to the generation of UFO packets that are smaller than the
MTU.  The software fallback path simply discards these packets.

This patch fixes the problem by not generating such packets on
the UFO path.

Signed-off-by: Herbert Xu 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller

ipmr: dont corrupt lists

2010-06-07T09:57:14+00:00

ipmr_rules_exit() and ip6mr_rules_exit() free a list of items, but
forget to properly remove these items from list. List head is not
changed and still points to freed memory.

This can trigger a fault later when icmpv6_sk_exit() is called.

Fix is to either reinit list, or use list_del() to properly remove items
from list before freeing them.

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

Introduced by commit d1db275dd3f6e4 (ipv6: ip6mr: support multiple
tables) and commit f0ad0860d01e (ipv4: ipmr: support multiple tables)

Reported-by: Alex Zhavnerchik 
Signed-off-by: Eric Dumazet 
CC: Patrick McHardy 
Signed-off-by: David S. Miller

tcp: use correct net ns in cookie_v4_check()

2010-06-04T22:56:03+00:00

Its better to make a route lookup in appropriate namespace.

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

rps: tcp: fix rps_sock_flow_table table updates

2010-06-04T22:56:02+00:00

I believe a moderate SYN flood attack can corrupt RFS flow table
(rps_sock_flow_table), making RPS/RFS much less effective.

Even in a normal situation, server handling short lived sessions suffer
from bad steering for the first data packet of a session, if another SYN
packet is received for another session.

We do following action in tcp_v4_rcv() :

	sock_rps_save_rxhash(sk, skb->rxhash);

We should _not_ do this if sk is a LISTEN socket, as about each
packet received on a LISTEN socket has a different rxhash than
previous one.
 -> RPS_NO_CPU markers are spread all over rps_sock_flow_table.

Also, it makes sense to protect sk->rxhash field changes with socket
lock (We currently can change it even if user thread owns the lock
and might use rxhash)

This patch moves sock_rps_save_rxhash() to a sock locked section,
and only for non LISTEN sockets.

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