Bug 17019

Summary: Re: arpintr() incorrectly checks mbuf chain size
Product: Base System Reporter: Robert Watson <robert>
Component: kernAssignee: GNATS administrator <gnats-admin>
Status: Closed FIXED    
Severity: Affects Only Me CC: FreeBSD-gnats-submit
Priority: Normal    
Version: 1.0-RELEASE   
Hardware: Any   
OS: Any   

Description Robert Watson 2000-02-27 15:50:01 UTC
 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:08 UTC
State Changed
From-To: open->closed

Intended as a followup to kern/16950.