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>
