From yar@yar.chem.msu.su  Sat Oct 21 02:44:23 2000
Return-Path: <yar@yar.chem.msu.su>
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
Sender: yar@yar.chem.msu.su
Reply-To: yar@comp.chem.msu.su
To: FreeBSD-gnats-submit@freebsd.org
Subject: in_arpinput() doesn't call m_pullup() while it should
X-Send-Pr-Version: 3.2

>Number:         22177
>Category:       kern
>Synopsis:       in_arpinput() doesn't call m_pullup() while it should
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    yar
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 21 02:50:01 PDT 2000
>Closed-Date:    Sat Mar 31 03:11:14 PST 2001
>Last-Modified:  Sat Mar 31 03:11:57 PST 2001
>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:
State-Changed-From-To: open->closed 
State-Changed-By: yar 
State-Changed-When: Tue Mar 27 04:36:42 PST 2001 
State-Changed-Why:  
Fixed 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22177 
State-Changed-From-To: closed->analyzed 
State-Changed-By: yar 
State-Changed-When: Tue Mar 27 05:33:11 PST 2001 
State-Changed-Why:  
Reopen the PR and assign it to myself 
because the fix went only to -current right now 
and needs to be MFCed to -stable in perspective. 


Responsible-Changed-From-To: freebsd-bugs->yar 
Responsible-Changed-By: yar 
Responsible-Changed-When: Tue Mar 27 05:33:11 PST 2001 
Responsible-Changed-Why:  
It's me who deals with the problem. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22177 
State-Changed-From-To: analyzed->closed 
State-Changed-By: yar 
State-Changed-When: Sat Mar 31 03:11:14 PST 2001 
State-Changed-Why:  
Fixed in both branches 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22177 
>Unformatted:
