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

[PATCH] NETLINK: Infinite recursion in netlink.

2007-04-25T21:12:21+00:00

[NETLINK]: Infinite recursion in netlink.

Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
which resulted in infinite recursion and stack overflow.

The bug is present in all kernel versions since the feature appeared.

The patch also makes some minimal cleanup:

1. Return something consistent (-ENOENT) when fib table is missing
2. Do not crash when queue is empty (does not happen, but yet)
3. Put result of lookup

Signed-off-by: Alexey Kuznetsov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

softmac: avoid assert in ieee80211softmac_wx_get_rate

2007-04-13T20:47:17+00:00

[PATCH] softmac: avoid assert in ieee80211softmac_wx_get_rate

Unconfigured bcm43xx device can hit an assert() during wx_get_rate
queries.  This is because bcm43xx calls ieee80211softmac_start late
(i.e. during open instead of probe).

   bcm43xx_net_open ->
      bcm43xx_init_board ->
         bcm43xx_select_wireless_core ->
            ieee80211softmac_start

Fix is to check that device is running before completing
ieee80211softmac_wx_get_rate.

Signed-off-by: John W. Linville 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

Fix TCP slow_start_after_idle sysctl

2007-04-13T20:47:05+00:00

[TCP]: slow_start_after_idle should influence cwnd validation too

For the cases that slow_start_after_idle are meant to deal
with, it is almost a certainty that the congestion window
tests will think the connection is application limited and
we'll thus decrease the cwnd there too.  This defeats the
whole point of setting slow_start_after_idle to zero.

So test it there too.

We do not cancel out the entire tcp_cwnd_validate() function
so that if the sysctl is changed we still have the validation
state maintained.

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

Fix tcindex classifier ABI borkage...

2007-04-13T20:47:05+00:00

[NET_SCHED]: cls_tcindex: fix compatibility breakage

Userspace uses an integer for TCA_TCINDEX_SHIFT, the kernel was changed
to expect and use a u16 value in 2.6.11, which broke compatibility on
big endian machines. Change back to use int.

Reported by Ole Reinartz 

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix IPSEC replay window handling

2007-04-13T20:47:05+00:00

[IPSEC]: Reject packets within replay window but outside the bit mask

Up until this point we've accepted replay window settings greater than
32 but our bit mask can only accomodate 32 packets.  Thus any packet
with a sequence number within the window but outside the bit mask would
be accepted.

This patch causes those packets to be rejected instead.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix TCP receiver side SWS handling.

2007-04-13T20:47:04+00:00

[TCP]: Do receiver-side SWS avoidance for rcvbuf < MSS.

Signed-off-by: John Heffner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix length validation in rawv6_sendmsg()

2007-04-13T20:47:04+00:00

[IPv6]: Fix incorrect length check in rawv6_sendmsg()

In article <20070329.142644.70222545.davem@davemloft.net> (at Thu, 29 Mar 2007 14:26:44 -0700 (PDT)), David Miller  says:

> From: Sridhar Samudrala 
> Date: Thu, 29 Mar 2007 14:17:28 -0700
>
> > The check for length in rawv6_sendmsg() is incorrect.
> > As len is an unsigned int, (len < 0) will never be TRUE.
> > I think checking for IPV6_MAXPLEN(65535) is better.
> >
> > Is it possible to send ipv6 jumbo packets using raw
> > sockets? If so, we can remove this check.
>
> I don't see why such a limitation against jumbo would exist,
> does anyone else?
>
> Thanks for catching this Sridhar.  A good compiler should simply
> fail to compile "if (x < 0)" when 'x' is an unsigned type, don't
> you think :-)

Dave, we use "int" for returning value,
so we should fix this anyway, IMHO;
we should not allow len > INT_MAX.

Signed-off-by: YOSHIFUJI Hideaki 
Acked-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix IFB net driver input device crashes

2007-04-13T20:47:04+00:00

[IFB]: Fix crash on input device removal

The input_device pointer is not refcounted, which means the device may
disappear while packets are queued, causing a crash when ifb passes packets
with a stale skb->dev pointer to netif_rx().

Fix by storing the interface index instead and do a lookup where neccessary.

Signed-off-by: Patrick McHardy 
Acked-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: ipt_CLUSTERIP: fix oops in checkentry function

2007-04-13T20:47:03+00:00

[NETFILTER]: ipt_CLUSTERIP: fix oops in checkentry function

The clusterip_config_find_get() already increases entries reference
counter, so there is no reason to do it twice in checkentry() callback.

This causes the config to be freed before it is removed from the list,
resulting in a crash when adding the next rule.

Signed-off-by: Jaroslav Kysela 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

APPLETALK: Fix a remotely triggerable crash

2007-04-06T10:43:18+00:00

When we receive an AppleTalk frame shorter than what its header says,
we still attempt to verify its checksum, and trip on the BUG_ON() at
the end of function atalk_sum_skb() because of the length mismatch.

This has security implications because this can be triggered by simply
sending a specially crafted ethernet frame to a target victim,
effectively crashing that host. Thus this qualifies, I think, as a
remote DoS. Here is the frame I used to trigger the crash, in npg
format:

{
# Ethernet header -----

XX XX XX XX XX XX # Destination MAC
00 00 00 00 00 00 # Source MAC
00 1D # Length

# LLC header -----

AA AA 03
08 00 07 80 9B # Appletalk

# Appletalk header -----

00 1B # Packet length (invalid)
00 01 # Fake checksum
00 00 00 00 # Destination and source networks
00 00 00 00 # Destination and source nodes and ports

# Payload -----

0C 0D 0E 0F 10 11 12 13
14
}

The destination MAC address must be set to those of the victim.

The severity is mitigated by two requirements:
* The target host must have the appletalk kernel module loaded. I
suspect this isn't so frequent.
* AppleTalk frames are non-IP, thus I guess they can only travel on
local networks. I am no network expert though, maybe it is possible
to somehow encapsulate AppleTalk packets over IP.

The bug has been reported back in June 2004:
http://bugzilla.kernel.org/show_bug.cgi?id=2979
But it wasn't investigated, and was closed in July 2006 as both
reporters had vanished meanwhile.

This code was new in kernel 2.6.0-test5:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=7ab442d7e0a76402c12553ee256f756097cae2d2
And not modified since then, so we can assume that vanilla kernels
2.6.0-test5 and later, and distribution kernels based thereon, are
affected.

Note that I still do not know for sure what triggered the bug in the
real-world cases. The frame could have been corrupted by the kernel if
we have a bug hiding somewhere. But more likely, we are receiving the
faulty frame from the network.

Signed-off-by: Jean Delvare
Signed-off-by: David S. Miller
Signed-off-by: Chris Wright
Signed-off-by: Greg Kroah-Hartman