Bug 17021

Summary: Re: arpintr() incorrectly checks mbuf chain size
Product: Base System Reporter: Jordan K. Hubbard <jkh>
Component: kernAssignee: GNATS administrator <gnats-admin>
Status: Closed FIXED    
Severity: Affects Only Me CC: csg
Priority: Normal    
Version: 1.0-RELEASE   
Hardware: Any   
OS: Any   

Description Jordan K. Hubbard 2000-02-27 19:10:01 UTC
 Yes, I approved these awhile back.
 
 > 
 > Jordan -- did it end up being the case that you did approve this fix, or
 > did not?
 > 
 > On Thu, 24 Feb 2000 csg@waterspout.com wrote:
 > 
 > > 
 > > >Submitter-Id:   current-users
 > > >Originator:     C. Stephen Gunn
 > > >Organization:   WaterSpout Communications, Inc.
 > > >Confidential:   no
 > > >Synopsis:       arpintr() incorrectly checks mbuf chain size
 > > >Severity:       serious
 > > >Priority:       high
 > > >Category:       kern
 > > >Release:        FreeBSD 3.4-STABLE i386
 > > >Class:          sw-bug
 > > >Environment: 
 > > 
 > > FreeBSD-3.4-STABLE or FreeBSD-4.0 current.
 > > 
 > > >Description: 
 > > 
 > > The NETISR_ARP handler arpintr() incorrectly checks m->m_len to
 > > determine if we have a complete ARP packet.  It is possible to
 > > have a packet spread across several mbufs in the chain.
 > > 
 > > While this case apparently doesn't happen with normal ethernet
 > > interfaces, additional mbuf operations before ARP processing (for
 > > 802.1Q Tagged VLANS, Bridged Ethernet over Frame Relay, or perhaps
 > > LANE) can cause NETISR_ARP to be presented with a fragmented packet.
 > > 
 > > >How-To-Repeat: 
 > > 
 > > Run my yet-to-see-the-light-of-day VLAN improvements, it blows chunks
 > > on ever inbound ARP packet.
 > > 
 > > >Fix: 
 > > 
 > > I've not only fixed the length comparisson, I've added several
 > > diagnostic error messages to the handler for other out-of-the-norm
 > > ARP packets.  This makes the error conditions easier to detect
 > > and fix, and makes the code much more readable.
 > > 
 > > I've put patches for -STABLE and -CURRENT (which are actually
 > > identical) online:
 > > 
 > >    http://www.waterspout.com/FreeBSD/arpintr-patch.current
 > > 
 > >    http://www.waterspout.com/FreeBSD/arpintr-patch.stable
 > > 
 > > If someone could perform a sanity check, and get these committed
 > > before 4.0-R heads out the door, that would be ideal.
 > > 
 > >  - Steve
 > > 
 > > 
 > 
 > 
 >   Robert N M Watson 
 > 
 > robert@fledge.watson.org              http://www.watson.org/~robert/
 > PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
 > TIS Labs at Network Associates, Safeport Network Services
 >
Comment 1 Steve Price freebsd_committer freebsd_triage 2000-02-28 04:07:44 UTC
State Changed
From-To: open->closed

Intended as a followup to kern/16950.