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

[NET_SCHED]: cls_tcindex: fix compatibility breakage

2007-04-13T20:58:27+00:00

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: Adrian Bunk

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

2007-04-13T20:58:27+00:00

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: Adrian Bunk

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

2007-04-13T20:58:26+00:00

Signed-off-by: John Heffner 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

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

2007-04-13T20:58:26+00:00

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: Adrian Bunk

[NET_SCHED]: cls_basic: fix memory leak in basic_destroy

2007-04-13T20:58:25+00:00

tp->root is not freed on destruction.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

APPLETALK: Fix a remotely triggerable crash (CVE-2007-1357)

2007-04-10T21:06:06+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: Adrian Bunk

tcp: fix cubic scaling error

2007-04-08T21:45:04+00:00

Doug Leith observed a discrepancy between the version of CUBIC described
in the papers and the version in 2.6.18. A math error related to scaling
causes Cubic to grow too slowly.

Patch is from "Sangtae Ha" . I validated that
it does fix the problems.

See the following to show behavior over 500ms 100 Mbit link.

Sender (2.6.19-rc3) ---  Bridge (2.6.18-rt7) ------- Receiver (2.6.19-rc3)
                    1G      [netem]           100M

        http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-orig.png
        http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-fix.png

Signed-off-by: Stephen Hemminger 
Signed-off-by: Adrian Bunk

[IFB]: Fix crash on input device removal

2007-04-03T02:03:55+00:00

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 
Signed-off-by: Adrian Bunk

[IPV6] HASHTABLES: Use appropriate seed for caluculating ehash index.

2007-03-28T20:04:44+00:00

Tetsuo Handa  told me that connect(2) with TCPv6
socket almost always took a few minutes to return when we did not have any
ports available in the range of net.ipv4.ip_local_port_range.

The reason was that we used incorrect seed for calculating index of
hash when we check established sockets in __inet6_check_established().

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

[NET_SCHED]: Fix ingress locking

2007-03-28T19:58:20+00:00

Ingress queueing uses a seperate lock for serializing enqueue operations,
but fails to properly protect itself against concurrent changes to the
qdisc tree. Use queue_lock for now since the real fix it quite intrusive.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk