Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Sign up!
EnGarde Community
What is the most important Linux security technology?
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Latest Newsletters
Linux Advisory Watch: March 27th, 2015
Linux Security Week: March 23rd, 2015
LinuxSecurity Newsletters
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

NetBSD-SA1999-001 select(2)/accept(2) race condition in TCP servers Print E-mail
User Rating:      How can I rate this item?
Posted by Team   
NetBSD select(2)/accept(2) race condition in TCP servers

                 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.


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

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:

Thanks To

Thanks go to Fyodor for providing nmap, with which this vulnerability
was discovered.  See for more information.
Thanks to Charles M. Hannum  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.

Version: 2.6.3i
Charset: noconv

< Prev   Next >


Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
FBI Quietly Removes Recommendation To Encrypt Your Phone
And the prize for LEAST SECURE BROWSER goes to ... Chrome!
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2015 Guardian Digital, Inc. All rights reserved.