[FEISTY] CVE-2007-1357: [APPLETALK]: Fix a remotely triggerable crash

Phillip lougher phillip at lougher.demon.co.uk
Tue May 1 23:49:03 UTC 2007

>From e07e67ac079deb5cd9b42bc110aa90a0119186db Mon Sep 17 00:00:00 2001
From: Jean Delvare <jdelvare at suse.de>
Date: Wed, 4 Apr 2007 23:52:46 -0700
Subject: [PATCH] [APPLETALK]: Fix a remotely triggerable crash (CVE-2007-1357)

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

<Appletalk Killer>

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

  AA AA 03
  08 00 07 80 9B  # Appletalk

  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

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

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:
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:
And not modified since then, so we can assume that vanilla kernels
2.6.0-test5 and later, and distribution kernels based thereon, are

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 <jdelvare at suse.de>
Signed-off-by: David S. Miller <davem at davemloft.net>
 net/appletalk/ddp.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index 3a70522..7c69506 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -1417,10 +1417,13 @@ static int atalk_rcv(struct sk_buff *skb, struct net_device *dev,
 	 * 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

More information about the kernel-team mailing list