Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9

[Mike Frysinger]

On Thursday 29 January 2009 03:47:48 Tobias Klausmann wrote:
> Hi!
>
> On Wed, 28 Jan 2009, Mike Frysinger wrote:
> > > On the wire between the client and the firewall, this happens:
> > >
> > > a packet 1 is sent
> > > b packet 2 is sent
> > > c answer 1 is received
> > > d answer 2 is received
> > >
> > > Sometimes d doesn't happen because b is lost in the firewall
> > > along the way (where the race condition happens).
> >
> > does this affect actual userspace behavior ?  in other words,
> > does this lead to lost lookups and errors from the resolver ?
>
> The most visible effect (and the way we found out about it first)
> is a 5s hang on ssh connects.

this is why i turn off dns lookup in all my sshd_config's (well, not because 
of this bug, but because DNS lookup on ssh can cause annoying delays).  plus, 
that info is largely useless: for the logged attempts from "bad" people, the 
dns is usually screwed up / wrong / unavailable anyways.

> Thing is: how long that timeout is
> is program dependant (whatever they use in select()). A recvfrom()
> simply hangs. I wrote a simple C program to do what glibc does
> (simplified for brevity):
> ...

so glibc will not trigger hangs, just delays in some cases.

> A "quickfix" would indeed be using two different ports for the
> queries - but the bug in Netfilter would still be there.

sure, the bug still exists in netfilter (kernel).  but if we can easily 
mitigate the effects seen by applications using glibc's resolver code, that 
seems sane to me.  i havent perused the glibc resolver code in a while ... do 
you know if it can easily be tweaked to use different ports, or would such a 
change be invasive ?  if the latter, well i guess we'll have to suck it up.
-mike