[5359] in bugtraq
Re: TCPwrappers race condition
daemon@ATHENA.MIT.EDU (Thamer Al-Herbish)
Mon Oct 6 11:00:43 1997
Date: Sun, 5 Oct 1997 18:44:28 +0300
Reply-To: shadows@whitefang.com
From: Thamer Al-Herbish <shadows@WHITEFANG.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199710051251.IAA05384@Twig.Rodents.Montreal.QC.CA>
On Sun, 5 Oct 1997, der Mouse wrote:
> One could argue that this is a bug; I certainly hold this view. There
> is room to argue about where the bug is; for example, in this
> situation, should the accept() fail? (One can't just destroy the queue
> entry, because when the PCB was queued, userland was promised (via a
> select() wakeup or equivalent) that accept() would not block.) Or
> should the kernel maintain a PCB and mark it as CLOSED so that the
> accept() returns an already-shut-down connection? Or what?
Accept could fail with an error indicating the connection had closed before
the accept() call was made. The struct sockaddr_in would be filled, and life
would go on. Mind you this is'nt documented anywhere, but I wonder if anyone
has implemented it.
Although it may sound ridiculous, having the kernel keep a list of "bad
connections" means resources can be exhausted by a malicious entity.
Although not very feasible, you could starve it with alot of PCBs.
--
Thamer Al-Herbish [ For PGP Key finger shadows@kuwait.net ]
shadows@whitefang.com
shadows@kuwait.net
