From jin@eubie.lbl.gov  Wed Apr 24 18:16:24 2002
Return-Path: <jin@eubie.lbl.gov>
Received: from eubie.lbl.gov (eubie.lbl.gov [131.243.2.36])
	by hub.freebsd.org (Postfix) with ESMTP id C08D137B400
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 24 Apr 2002 18:16:23 -0700 (PDT)
Received: (from jim@localhost)
	by eubie.lbl.gov (8.11.6/8.11.6) id g3P1EOZ28984;
	Wed, 24 Apr 2002 18:14:24 -0700 (PDT)
	(envelope-from jin)
Message-Id: <200204250114.g3P1EOZ28984@eubie.lbl.gov>
Date: Wed, 24 Apr 2002 18:14:24 -0700 (PDT)
From: Jin Guojun (DSD staff) <jin@eubie.lbl.gov>
Reply-To: j_guojun@lbl.gov
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: accept dead loop when out of file descriptor
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         37436
>Category:       kern
>Synopsis:       [hang] accept dead loop when out of file descriptors
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Apr 24 18:20:00 PDT 2002
>Closed-Date:    Tue Jan 08 06:53:10 UTC 2008
>Last-Modified:  Tue Jan 08 06:53:10 UTC 2008
>Originator:     Jin Guojun (DSD staff)
>Release:        FreeBSD 4.5-RELEASE i386
>Organization:
>Environment:

	FreeBSD 4.5-RELEASE (May be all)

>Description:
	If a user or system file descriptor table is full, the accept()
	will infinitly return an error EMFILE/ENFILE.
 
>How-To-Repeat:
	Set file descriptor table limit (from csh/tcsh):

	% limit descriptors 16 (or some reasonable number for testing)

	Then, open a TCP socket and listen on it, and start to connect
	to this TCP port from localhost or a remote host in muliple times.

	iperf may be an existing program to test this problem.
	To compile iperf in multi-thread mode, link libc_r.a to libpthead.a
	before doing the configure under iperf.

	Then start iperf server on a FreeBSD host that descriptors is limited.
	server% limit descriptors 16
	server% iperf -s

	On any other host to start a client and make 16 connections:
	remote% iperf -c server -P 16

	Program will hang on both systems. To trace it, use perror()
	to print error message after accept() when accept() return -1.

>Fix:

	The correct behave should close the duplicate socket to cause
	remote connection go away.

	Just for reference:
	This was tested under thread environment (-lc_r).
	I have not tested this under fork(), and this may only
	happened under libc_r.a, but it is possible inside the kernel.
	If this is true, then it can lead to DOS attack. An intruder
	can start connect to a port until a connect() call hangs,
	then kill rest connections and leave the last one alive to
	hang a remote server.

	The similar problem happens under Solaris.
	Linux implements this correctly.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: kmacy 
State-Changed-When: Sat Nov 17 01:19:37 UTC 2007 
State-Changed-Why:  

Is this still an issue? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=37436 
State-Changed-From-To: feedback->closed 
State-Changed-By: remko 
State-Changed-When: Tue Jan 8 06:53:09 UTC 2008 
State-Changed-Why:  
Jin Guojun reports that this can be closed, make it happen... 

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