Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Jan 2000 09:54:16 -0700
From:      Brett Glass <brett@lariat.org>
To:        Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
Cc:        Darren Reed <avalon@coombs.anu.edu.au>, security@FreeBSD.ORG
Subject:   Re: stream.c worst-case kernel paths
Message-ID:  <4.2.2.20000121094204.01a57d50@localhost>
In-Reply-To: <20000121102908.A4494@daemon.ninth-circle.org>
References:  <4.2.2.20000120212336.01882220@localhost> <4.2.2.20000120182425.01886ec0@localhost> <200001210417.PAA24853@cairo.anu.edu.au> <4.2.2.20000120212336.01882220@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help
At 02:29 AM 1/21/2000 , Jeroen Ruigrok/Asmodai wrote:

> >The odds of the source ports being the same are minuscule. Wouldn't this
> >prevent a problem? Or am I misunderstanding the implications here?
>
>Stevens' TCPv1, Chapter 18.8.
>
>Although I am not sure about the implications of the exact same numbered
>source ports.  If that is what Darren is saying.  Could also be the same
>destination ports.

Let's recap. We were discussing the code for in_pcblookup_hash() in the
file in_pcb.c, and the code which calls it in tcp_input.c.

I noted that when a TCP packet comes in, the code searches for an
associated socket with the call

         inp = in_pcblookup_hash(&tcbinfo, ti->ti_src, ti->ti_sport,
             ti->ti_dst, ti->ti_dport, 1);

Note that the last parameter, "wildcard," is always set to 1. This
means that two lookups are done if necessary. in_pcblookup_hash
first looks for an already open socket, and if that fails it looks
for a listener. This second search (badly named, IMHO; it should
really say something like "lookforlistener") is done only if the 
"wildcard" flag is set.

What I said was that we should only be looking for a listener if
the packet is a SYN; that is, if SYN is set and RST and ACK (and,
probably, FIN too) are clear. If it's not something that can start
a connection, I can't see why looking for a listener is productive.

Darren said that this might cause problems in the case of simultaneous
attempted connections in both directions, but I couldn't see how.

--Brett



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20000121094204.01a57d50>