Re: BUG: Major TCP connect() errors, don't release as stable.

[Stephen Hemminger <shemminger@osdl.org>]

On Fri, 10 Jun 2005 14:16:32 +0000
Alastair Poole <alastair@unixtrix.com> wrote:

> I have tested various kernels including 2.6.11.10 2.6.11.11 and
> 2.6.12-rc6 and am having unusual results regarding connect().  Earlier
> kernels do not return the same strange results.
> 
> I have tested numerous basic port scanners, including my own, and
> strangely ports which are NOT open are being reported as open.  I have
> checked these ports by various means -- to be certain they are NOT open
> -- and in various runlevels; the results are the same.  There are no TCP 
> daemons running, nor RPC services.  This is definately kerenl related.
> 
> The number of ports listed changes in size and they appear to be
> random.  For example, on one scan ports 22, 3455, 4532 and 6236 will
> appear open; on another scan it might be 22, 3567, 3879, 3889, 6589 and
> 7374.
> 
> However, ports which ARE open do also appear as open alongside these
> "rogue" ports.  I have also tested this on another system with the same
> results.  It is also interesting to note that a basic TCP nmap scan of 
> all ports does not return these unusual results.
> 
> I was initially told that the problem was not kernel related.  However, 
> I have now reconfirmed with three seperate sources.  This is, indeed, 
> quite a serious kernel related bug.  Please take this seriously.
> 
> Enclosed is example code that produces these results on the named
> kernels and systems.
> 
> sincerely
> 
> Alastair Poole

Looks like a simple interaction of "connect to self" allowed by RFC 793
to handle simultaneous connection and the TCP port randomization of ephemeral ports.