From nobody@FreeBSD.org  Mon Jun 25 20:42:59 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id EC47B37B401
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 25 Jun 2001 20:42:56 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.3/8.11.3) id f5Q3guO01335;
	Mon, 25 Jun 2001 20:42:56 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200106260342.f5Q3guO01335@freefall.freebsd.org>
Date: Mon, 25 Jun 2001 20:42:56 -0700 (PDT)
From: Ernest Hua <ernest@luminous.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: arplookup uses potentially unprotected static variable ...
X-Send-Pr-Version: www-1.0

>Number:         28417
>Category:       kern
>Synopsis:       arplookup uses potentially unprotected static variable ...
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bms
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun 25 20:50:02 PDT 2001
>Closed-Date:    Sat Nov 15 00:44:24 PST 2003
>Last-Modified:  Sat Nov 15 00:44:24 PST 2003
>Originator:     Ernest Hua
>Release:        4.2-RELEASE
>Organization:
Luminous Networks
>Environment:
FreeBSD ernestbsd.luminousnetworks.com 4.2-RELEASE FreeBSD 4.2-RELEASE #0: Mon Nov 20 13:02:55 GMT 2000     jkh@bento.FreeBSD.org:/usr/src/sys/compile/GENERIC  i386

>Description:
I suspect that there is a hidden problem in using this static variable
in arplookup.  We actually found this while working in VxWorks 5.4, but
it appears to be in FreeBSD and NetBSD as well.  I'll check a few other
OS's later.  The problem is the static variable "sin" in arplookup(),
which is used to hold the IP address to look up.  I am not a network
stack expert, but I suspect this path is not multi-thread friendly, and
will have potentially corrupted results for simultaneous callers.

>How-To-Repeat:

>Fix:
Remove the "static" keyword.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->bms 
Responsible-Changed-By: bms 
Responsible-Changed-When: Wed 1 Oct 2003 02:32:11 PDT 
Responsible-Changed-Why:  
I've informed sam, who is working on the netperf branch, and given 
him a diff, which I'm testing now. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=28417 
State-Changed-From-To: open->analyzed 
State-Changed-By: bms 
State-Changed-When: Wed 1 Oct 2003 06:50:21 PDT 
State-Changed-Why:  
A potential race condition exists in the current ARP code. It is 
possible in 5.x UP and SMP kernels that multiple callers could trigger 
a race here on the entry to rtalloc1(), although so far there have not 
been any reported occurrences of this. 

In 4.x there should be sufficient protection through use of splnet(). 
In 5.x this protection does not exist. sam@ is working on fine-grained 
locking for the network stack which should address this issue, and 
a 'starting point' patch is with him as explained above. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=28417 
State-Changed-From-To: analyzed->patched 
State-Changed-By: bms 
State-Changed-When: Fri 3 Oct 2003 10:35:29 PDT 
State-Changed-Why:  


http://www.freebsd.org/cgi/query-pr.cgi?pr=28417 
State-Changed-From-To: patched->analyzed 
State-Changed-By: bms 
State-Changed-When: Fri 3 Oct 2003 10:36:28 PDT 
State-Changed-Why:  
Snafu log message 

http://www.freebsd.org/cgi/query-pr.cgi?pr=28417 
State-Changed-From-To: analyzed->patched 
State-Changed-By: bms 
State-Changed-When: Fri 3 Oct 2003 10:37:01 PDT 
State-Changed-Why:  
Thanks for telling us about this issue. Sam has committed my fix 
to the netperf tree. I am marking this as patched for the time being; 
we will consider it closed when the final netperf merge into mainline 
development takes place probably in time for 5.2-RELEASE. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=28417 
State-Changed-From-To: patched->closed 
State-Changed-By: bms 
State-Changed-When: Sat 15 Nov 2003 00:42:28 PST 
State-Changed-Why:  
Believed that issue would affect the network stack post-locking-patches. 

Not believed that issue would affect 4.x SMP as the RELENG_4 branch 
still uses spl*() and friends to protect the sections involved. 

Something similar to the submitter's patch has been committed and will 
be present in 5.2-RELEASE. 

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