From: Chris Wright Date: Fri, 6 Apr 2007 00:16:39 +0000 (-0700) Subject: Add Appletalk fix from Jean Delvare X-Git-Tag: v2.6.20.5~4 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=827e52ab73f945c921c5c6d2073383234c6ec65c;p=thirdparty%2Fkernel%2Fstable-queue.git Add Appletalk fix from Jean Delvare --- diff --git a/review-2.6.20/fix-a-remotely-triggerable-crash.patch b/review-2.6.20/fix-a-remotely-triggerable-crash.patch new file mode 100644 index 00000000000..0f1b37f0b4b --- /dev/null +++ b/review-2.6.20/fix-a-remotely-triggerable-crash.patch @@ -0,0 +1,91 @@ +From 75559c167bddc1254db5bcff032ad5eed8bd6f4a Mon Sep 17 00:00:00 2001 +From: Jean Delvare +Date: Wed, 4 Apr 2007 23:52:46 -0700 +Subject: APPLETALK: Fix a remotely triggerable crash + +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 +--- + net/appletalk/ddp.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- linux-2.6.20.4.orig/net/appletalk/ddp.c ++++ linux-2.6.20.4/net/appletalk/ddp.c +@@ -1417,10 +1417,13 @@ static int atalk_rcv(struct sk_buff *skb + /* + * Size check to see if ddp->deh_len was crap + * (Otherwise we'll detonate most spectacularly +- * in the middle of recvmsg()). ++ * in the middle of atalk_checksum() or recvmsg()). + */ +- if (skb->len < sizeof(*ddp)) ++ if (skb->len < sizeof(*ddp) || skb->len < (len_hops & 1023)) { ++ pr_debug("AppleTalk: dropping corrupted frame (deh_len=%u, " ++ "skb->len=%u)\n", len_hops & 1023, skb->len); + goto freeit; ++ } + + /* + * Any checksums. Note we don't do htons() on this == is assumed to be diff --git a/review-2.6.20/series b/review-2.6.20/series index 0e5684b6be9..8cb884d5e03 100644 --- a/review-2.6.20/series +++ b/review-2.6.20/series @@ -35,3 +35,4 @@ libata-bugfix-hdio_drive_task.patch libata-sata_mv-don-t-touch-reserved-bits-in-edma-config-register.patch libata-sata_mv-fix-50xx-irq-mask.patch generic_serial-fix-decoding-of-baud-rate.patch +fix-a-remotely-triggerable-crash.patch