e2e3d0a401
mode. This addresses a well-known race condition that can cause servers to hang in accept(). The relevant case is when somebody connects to the server and then immediately kills the connection by sending a TCP reset. On the server this causes select to report a ready condition on the socket, after which the accept call blocks because there is no longer any pending connection to accept. In -current there is already a work-around for this in the kernel. It was merged into -stable some time ago, but then David Greenman reverted it because it seemed to be causing a socket leak in some cases. (See uipc_socket.c revision 1.51.2.3.) Hence this userland fix is needed in -stable, and I plan to merge it into that branch soon because it fixes a potential DoS attack. It may also be needed in -current if the suspected socket leak turns out to be real. In any case, after thinking it over I believe the fix belongs in userland. An application shouldn't assume that a ready return from select guarantees that the subsequent I/O operation cannot block. A lot can happen between the select and the accept. A similar fix should most likely be applied to the Unix domain socket transport too. Submitted by: peter Reviewed by: jdp |
||
---|---|---|
.. | ||
compat | ||
csu | ||
libalias | ||
libatm | ||
libbind | ||
libc | ||
libc_r | ||
libcalendar | ||
libcam | ||
libcom_err | ||
libcompat | ||
libcrypt | ||
libcurses | ||
libdevstat | ||
libdisk | ||
libedit | ||
libfetch | ||
libform | ||
libftpio | ||
libgnumalloc | ||
libio | ||
libipx | ||
libkse | ||
libkvm | ||
libm | ||
libmd | ||
libmenu | ||
libmytinfo | ||
libncp | ||
libncurses | ||
libnetgraph | ||
libopie | ||
libpam | ||
libpanel | ||
libpcap | ||
libpthread | ||
libradius | ||
libresolv | ||
librpcsvc | ||
libskey | ||
libss | ||
libstand | ||
libtacplus | ||
libtelnet | ||
libtermcap | ||
libutil | ||
libvgl | ||
libwrap | ||
libxpg4 | ||
liby | ||
libz | ||
msun | ||
ncurses | ||
Makefile | ||
Makefile.inc |