From nobody@FreeBSD.org  Tue Oct 24 07:00:55 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BDFD916A403
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 24 Oct 2006 07:00:55 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8CE9443D45
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 24 Oct 2006 07:00:55 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k9O70tx7006040
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 24 Oct 2006 07:00:55 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k9O70tKD006039;
	Tue, 24 Oct 2006 07:00:55 GMT
	(envelope-from nobody)
Message-Id: <200610240700.k9O70tKD006039@www.freebsd.org>
Date: Tue, 24 Oct 2006 07:00:55 GMT
From: user from china<nodummy@yeah.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [patch]Reentrant problem with inet_ntoa in the kernel
X-Send-Pr-Version: www-3.0

>Number:         104738
>Category:       kern
>Synopsis:       [inet] [patch] Reentrant problem with inet_ntoa in the kernel
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-net
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Oct 24 07:10:18 GMT 2006
>Closed-Date:    
>Last-Modified:  Wed Jul 03 01:33:36 UTC 2013
>Originator:     user from china
>Release:        7-CURRENT & 6.1-RELEASE
>Organization:
none
>Environment:
>Description:
The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static array 
static char buf[4 * sizeof "123"];
to store the result. And it returns the address of the array to the caller.

I think this inet_ntoa is not reentrant, though there are several functions
calling it. If two functions call it simultaneously, the result will be
corrupted. Though I haven't really encountered this situation, it may occur
someday, especially when using multi-processor.
>How-To-Repeat:

>Fix:
There is another reentrant version of inet_ntoa called inet_ntoa_r in the
same file. It has been there for several years, but just used by ipfw2 for
about four times in 7-CURRENT. In my patch, I replaced all the calls to
inet_ntoa with calls to inet_ntoa_r.

By the way, some of the original calls is written in this style:
strcpy(buf, inet_ntoa(ip))

The changed code looks like
inet_ntoa_r(ip, buf)
This change avoids a call to strcpy, and can save a little time.

Here is the patch.
http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-net
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->mlaier 
Responsible-Changed-By: mlaier 
Responsible-Changed-When: Thu Nov 2 19:03:59 UTC 2006 
Responsible-Changed-Why:  
Take over.  Allocating a buffer on stack for every (debugging) print of an 
internet address seems bloat, but this needs to be addressed nontheless. 
As an aside, ip6_sprintf() tries to use a round-robin buffer, but does not 
properly synchronize access to that, either.  This needs to be fixed as well. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=104738 
State-Changed-From-To: open->open 
State-Changed-By: linimon 
State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 
State-Changed-Why:  
commit bit has been taken in for safekeeping. 


Responsible-Changed-From-To: mlaier->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 
Responsible-Changed-Why:  

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