| 1 |
On Tuesday 27 January 2009 11:59:46 Tobias Klausmann wrote: |
| 2 |
> On Tue, 27 Jan 2009, Peter Alfredsen wrote: |
| 3 |
> > On Tue, 27 Jan 2009 16:47:50 +0100 Tobias Klausmann wrote: |
| 4 |
> > > glibc 2.9 uses a different way to implement getaddrinfo() which |
| 5 |
> > > triggers a race condition in most (if not all) Netfilter |
| 6 |
> > > firewalls that use connection tracking. glibc does nothing wrong |
| 7 |
> > > per se, it just triggers the condition. (technical details here: |
| 8 |
> > > http://marc.info/?l=linux-netdev&m=123304473331445) |
| 9 |
> > |
| 10 |
> > [...] |
| 11 |
> > |
| 12 |
> > > I don't have any experience with glibc upstream but pestering |
| 13 |
> > > them about this out of the blue might only cause a flame war |
| 14 |
> > > between kernel and glibc folks. Thus, I'm asking you, my fellow |
| 15 |
> > > devs (and the glibc and kernel teams specifically), what you |
| 16 |
> > > think is the best idea/course of action. |
| 17 |
> > |
| 18 |
> > The connection with IPv6 leads me to believe that this is |
| 19 |
> > http://bugs.gentoo.org/250468 |
| 20 |
> > http://sourceware.org/bugzilla/show_bug.cgi?id=7060 |
| 21 |
> |
| 22 |
> I doubt it: sometimes the lookups work, as this race is very |
| 23 |
> timing-critical. When experimenting, I had to go below 50 |
| 24 |
> microseconds between the two packets to actually trigger it plus |
| 25 |
> the forwarding machines always were multicore. Also, the content |
| 26 |
> is irrelevant. I implemented this myself sending the payloads |
| 27 |
> with sendto() and it didn't matter if I sent the A or AAAA query |
| 28 |
> first. |
| 29 |
> |
| 30 |
> That said, without seeing a tcpdump from those people with the |
| 31 |
> error described in those two bugs, I can not rule it out. |
| 32 |
|
| 33 |
the referenced bug generally deals with broken nameservers that cant handle |
| 34 |
the type of requests that glibc sends out (the requests are correct according |
| 35 |
to the relevant standards/RFCs, but apparently many DNS servers out there |
| 36 |
screw up with it due to the ipv4/ipv6 combo). |
| 37 |
|
| 38 |
the referenced thread seems to indicate even more the issue is in the |
| 39 |
netfilter code. |
| 40 |
|
| 41 |
> On the wire between the client and the firewall, this happens: |
| 42 |
> |
| 43 |
> a packet 1 is sent |
| 44 |
> b packet 2 is sent |
| 45 |
> c answer 1 is received |
| 46 |
> d answer 2 is received |
| 47 |
> |
| 48 |
> Sometimes d doesn't happen because b is lost in the firewall |
| 49 |
> along the way (where the race condition happens). |
| 50 |
|
| 51 |
does this affect actual userspace behavior ? in other words, does this lead |
| 52 |
to lost lookups and errors from the resolver ? |
| 53 |
-mike |
Archives