Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Feb 2000 00:50:03 -0500 (EST)
From:      csg@waterspout.com
To:        FreeBSD-gnats-submit@freebsd.org, csg@waterspout.com
Cc:        rwatson@freebsd.org, mdodd@freebsd.org, jkh@freebsd.org
Subject:   kern/16950: arpintr() incorrectly checks mbuf chain size
Message-ID:  <200002240550.AAA31092@squall.waterspout.com>

next in thread | raw e-mail | index | archive | help

>Number:         16950
>Category:       kern
>Synopsis:       arpintr() incorrectly checks mbuf chain size
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb 23 22:00:01 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     C. Stephen Gunn
>Release:        FreeBSD 3.4-STABLE i386
>Organization:
WaterSpout Communications, Inc.
>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


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


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002240550.AAA31092>