kernel.git/net/appletalk, branch linux-2.6.20.y

APPLETALK: Fix a remotely triggerable crash

2007-04-06T10:43:18Z

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

[PATCH] severing skbuff.h -> highmem.h

2006-12-04T07:00:29Z

Signed-off-by: Al Viro

[APPLETALK]: Fix potential OOPS in atalk_sendmsg().

2006-10-30T23:24:34Z

atrtr_find() can return NULL, so do not blindly dereference rt->dev before we check for rt being NULL. Signed-off-by: David S. Miller

[ATALK]: endianness annotations

2006-09-29T00:53:58Z

Signed-off-by: Al Viro Signed-off-by: David S. Miller

[NET]: Conversions from kmalloc+memset to k(z|c)alloc.

2006-07-21T21:51:30Z

Signed-off-by: Panagiotis Issaris Signed-off-by: David S. Miller

Remove obsolete #include

2006-06-30T17:25:36Z

Signed-off-by: Jörn Engel Signed-off-by: Adrian Bunk

[NET]: Fix ipx/econet/appletalk/irda ioctl crashes

2006-03-29T01:02:43Z

Fix kernel oopses whenever somebody issues compatible ioctl on AppleTalk, Econet, IPX or IRDA socket. For AppleTalk/Econet/IRDA it restores state in which these sockets were before compat_ioctl was introduced to the socket ops, for IPX it implements support for 4 ioctls which were not implemented before - as these ioctls use structures which match between 32bit and 64bit userspace, no special code is needed, just call 64bit ioctl handler. Signed-off-by: Petr Vandrovec Signed-off-by: David S. Miller

[PATCH] capable/capability.h (net/)

2006-01-12T02:42:14Z

net: Use where capable() is used. Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[NET]: Add a dev_ioctl() fallback to sock_ioctl()

2006-01-03T22:18:33Z

Currently all network protocols need to call dev_ioctl as the default fallback in their ioctl implementations. This patch adds a fallback to dev_ioctl to sock_ioctl if the protocol returned -ENOIOCTLCMD. This way all the procotol ioctl handlers can be simplified and we don't need to export dev_ioctl. Signed-off-by: Christoph Hellwig Signed-off-by: David S. Miller

[NET]: move struct proto_ops to const

2006-01-03T21:11:15Z

I noticed that some of 'struct proto_ops' used in the kernel may share a cache line used by locks or other heavily modified data. (default linker alignement is 32 bytes, and L1_CACHE_LINE is 64 or 128 at least) This patch makes sure a 'struct proto_ops' can be declared as const, so that all cpus can share all parts of it without false sharing. This is not mandatory : a driver can still use a read/write structure if it needs to (and eventually a __read_mostly) I made a global stubstitute to change all existing occurences to make them const. This should reduce the possibility of false sharing on SMP, and speedup some socket system calls. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller