Date: Wed, 24 Apr 2002 18:14:24 -0700 (PDT) From: Jin Guojun (DSD staff) <jin@eubie.lbl.gov> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/37436: accept dead loop when out of file descriptor Message-ID: <200204250114.g3P1EOZ28984@eubie.lbl.gov>
next in thread | raw e-mail | index | archive | help
>Number: 37436 >Category: kern >Synopsis: accept dead loop when out of file descriptor >Confidential: Yes >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Apr 24 18:20:00 PDT 2002 >Closed-Date: >Last-Modified: >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: >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?200204250114.g3P1EOZ28984>