Does Linux suffer from the following problem?

Regards
Peter Miller	E-Mail:	millerp@canb.auug.org.au
/\/\*		WWW:	http://www.canb.auug.org.au/~millerp/

> From auscert@auscert.org.au Fri Jan 22 08:20:46 1999
> Subject: (AUSCERT ESB-1999.003) NetBSD Security Advisory 1999-001 - select(2)/accept(2) race condition in TCP servers
> Date: 21 Jan 1999 17:35:53 +1100
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> ===========================================================================
>               AUSCERT External Security Bulletin Redistribution
>
>               ESB-1999.003 -- NetBSD Security Advisory 1999-001
>               select(2)/accept(2) race condition in TCP servers
>
>                               21 January 1999
>
> ===========================================================================
>
> The NetBSD Foundation, Inc. has released the following advisory concerning
> a vulnerability in the way many TCP based network services are provided.
> This vulnerability may allow remote attackers to wedge many TCP services
> causing denial of service.
>
> - ---------------------------BEGIN INCLUDED TEXT--------------------
>
> - -----BEGIN PGP SIGNED MESSAGE-----
>
>
>                  NetBSD Security Advisory 1999-001
>                  ---------------------------------
>
> Topic:		select(2)/accept(2) race condition in TCP servers
> Version:	All current versions of NetBSD
> Severity:	Problem may allow denial of service.
>
>
> Abstract
> ========
>
> A problem has been identified which allows remote attackers to wedge
> many TCP services running on 4.4BSD-derived systems, including X
> servers and all services run from inetd.  Other (non-BSD) systems are
> believed to be affected as well.
>
>
> Technical Details
> =================
>
> Many TCP servers open a TCP socket in the default blocking mode, use
> select(2) to wait for connections, and then accept(2) connections in
> blocking mode.  Under some circumstances, the accept(2) may hang
> waiting for another connection, denying service to clients trying to
> connect to other ports.
>
> The scenario which causes this is:
>
> * Connection is initiated by client; 3WHS completes.
> * Server process is awakened and select(2) succeeds.
> * Connection is closed by client (e.g. by sending a RST).  Connection
>   is removed from accept(2) queue on server.
> * Server process does an accept(2), which hangs waiting for a
>   connection.
>
> This scenario is sometimes difficult to reproduce, particularly if the
> server is very fast and the network is relatively slow.  It is most
> effective if the server is slow and/or must do a lot of work between
> the select(2) and accept(2).
>
>
> Solutions and Workarounds
> =========================
>
> Two solutions are possible:
>
> 1) Modify all TCP servers to use non-blocking listening sockets.
>    Unfortunately, this requires changing a large amount of code, much
>    of it maintained by third parties.
>
> 2) Modify the kernel to not remove sockets from the accept(2) queue
>    when they are closed.  A change that implements this has been added
>    to NetBSD-current, and is available at:
>        ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/patches/19990120-accept
>
>
> Thanks To
> =========
>
> Thanks go to Fyodor for providing nmap, with which this vulnerability
> was discovered.  See http://www.insecure.org/nmap/ for more information.
> Thanks to Charles M. Hannum <root@ihack.net> for providing the solution.
>
>
> More Information
> ================
>
> Information about NetBSD and NetBSD security can be found at
> http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/.
>
>
> Copyright 1999, The NetBSD Foundation.  All Rights Reserved.
>
>
> - -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQCVAwUBNqWj/D5Ru2/4N2IFAQF3AwP7B/sbL1Ar8NCP/vLIaeYq698bSR2SIQRC
> 21yFSNY7h0qGxpsEtJ0132wIHVYp4Ho3Pbd1308ZOykx22zfZr11IlkgInW8kFKf
> 7K2yQOc47RAKxyaAZvgR/oqUCQE+FiZ4DYv4WDjkbUluYpcxnHmbhO/tIqbYHJqE
> ue/dnlXwvcA=
> =GHyB
> - -----END PGP SIGNATURE-----
>
> - ----------------------------END INCLUDED TEXT--------------------
>
> This security bulletin is provided as a service to AusCERT's members.  As
> AusCERT did not write the document quoted above, AusCERT has had no control
> over its content.  The decision to use any or all of this information is
> the responsibility of each user or organisation, and should be done so in
> accordance with site policies and procedures.
>
> NOTE: This is only the original release of the security bulletin.  It will
> not be updated when updates to the original are made.  If downloading at
> a later date, it is recommended that the bulletin is retrieved directly
> from the original authors to ensure that the information is still current.
>
> Contact information for the authors of the original document is included
> in the Security Bulletin above.  If you have any questions or need further
> information, please contact them directly.
>
> Previous advisories and external security bulletins can be retrieved from:
>
>         http://www.auscert.org.au/Information/advisories.html
>
> If you believe that your system has been compromised, contact AusCERT or
> your representative in FIRST (Forum of Incident Response and Security
> Teams).
>
> Internet Email: auscert@auscert.org.au
> Facsimile:      (07) 3365 7031
> Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
>                 AusCERT personnel answer during Queensland business hours
>                 which are GMT+10:00 (AEST).
>                 On call after hours for emergencies.
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key
>
> iQCVAwUBNqdWfSh9+71yA2DNAQE4lgP/ePOcrksrOcoF8o6kw8XRPZ3TA9Vms+nt
> WZtfS53f0vlp4abngl5PdMF54P2G0tQWyGRlLsKpuo/HgU+Ebf/vE5FwO85cjMvZ
> mjDfzmy3RUjhfUeVUpkB6Od7EkgytoNOq3+q+eicwZFHP0WUe0UJBqmnPR2ibHMY
> zxD1DN14llk=
> =b8No
> -----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/