From owner-freebsd-bugs  Sat Oct 21  2:50:11 2000
Delivered-To: freebsd-bugs@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id D1D2937B4D7
	for <freebsd-bugs@FreeBSD.org>; Sat, 21 Oct 2000 02:50:01 -0700 (PDT)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id CAA41208;
	Sat, 21 Oct 2000 02:50:01 -0700 (PDT)
	(envelope-from gnats@FreeBSD.org)
Received: from yar.chem.msu.su (yar.chem.msu.ru [195.208.208.25])
	by hub.freebsd.org (Postfix) with ESMTP id 0C8D537B4CF
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 21 Oct 2000 02:44:21 -0700 (PDT)
Received: (from yar@localhost)
	by yar.chem.msu.su (8.11.0/8.11.0) id e9L9iJZ00639;
	Sat, 21 Oct 2000 13:44:19 +0400 (MSD)
	(envelope-from yar)
Message-Id: <200010210944.e9L9iJZ00639@yar.chem.msu.su>
Date: Sat, 21 Oct 2000 13:44:19 +0400 (MSD)
From: yar@comp.chem.msu.su
Reply-To: yar@comp.chem.msu.su
To: FreeBSD-gnats-submit@freebsd.org
X-Send-Pr-Version: 3.2
Subject: kern/22177: in_arpinput() doesn't call m_pullup() while it should
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>Number:         22177
>Category:       kern
>Synopsis:       in_arpinput() doesn't call m_pullup() while it should
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 21 02:50:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Yar Tikhiy
>Release:        FreeBSD 4.1-STABLE i386
>Organization:
Moscow State University
>Environment:

	The bug show up in all branches.

>Description:

	The processing of incoming ARP packets is split into two
	parts, the lower one (arpintr()) being protocol-independent,
	and the uppper one (in_arpinput) being IP-specific. The
	lower one uses m_pullup() to ensure the arp header is
	contiguous in memory and can be accessed with mtod().
	However, the length of data being pulled up is smaller than
	required for IP ARP (but still enough for the protocol-independent
	part of the ARP header). The upper part doesn't call
	m_pullup() at all and so can be made by a malicious cracker
	sending too short ARP packets to access memory beyond the
	actual data boundary. Of course, there is usually some
	spare space in a mbuf cluster there, but that's still a
	dangerous behaviour.

	Moreover, that may break some sophisticated encapsulation
	schemes, such as VLANs (and it does break in some cases)

	Thus, yet another m_pullup() won't hurt.

>How-To-Repeat:

	Take a look at the code in file netinet/if_ether.c,
	functions arpintr() and in_arpinput()

>Fix:

--- netinet/if_ether.c.orig	Tue Apr 11 11:08:35 2000
+++ netinet/if_ether.c	Fri Oct 20 03:03:23 2000
@@ -506,6 +506,12 @@
 	struct in_addr isaddr, itaddr, myaddr;
 	int op;
 
+	if (m->m_len < sizeof(struct ether_arp) &&
+	    (m = m_pullup(m, sizeof(struct ether_arp))) == NULL) {
+		log(LOG_ERR, "arp: runt packet -- m_pullup failed\n");
+		return;
+	}
+
 	ea = mtod(m, struct ether_arp *);
 	op = ntohs(ea->arp_op);
 	(void)memcpy(&isaddr, ea->arp_spa, sizeof (isaddr));

>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message