From: Ulrich Weber <uweber@astaro.com>
To: Changli Gao <xiaosuo@gmail.com>
Cc: Ulrich Weber <uweber@astaro.com>, netfilter-devel@vger.kernel.org
Subject: Re: [RFC PATCH] nfqueue: nf_conntrack_confirm race condition
Date: Mon, 22 Nov 2010 13:34:52 +0100 [thread overview]
Message-ID: <4CEA636C.80904@astaro.com> (raw)
In-Reply-To: <AANLkTimFXUSKTLLMiDVH8Rb0kjVFhtQZQtm+zKT75jhk@mail.gmail.com>
Yes you are right, queuing could be done in raw table PRE_ROUTING and
LOCAL_OUT. However I dont like the idea of queuing packets which are
going to be dropped anyway, could trigger an DOS attack.
We could add two additional raw hooks for LOCAL_IN and POST_ROUTING,
after conntrack is confirmed and queue packets then...
Conntrack lookup after reinjection is racy too with multiple queues.
Cheers
Ulrich
On 11/20/2010 07:49 AM, Changli Gao wrote:
> On Fri, Nov 19, 2010 at 5:58 PM, Ulrich Weber <uweber@astaro.com> wrote:
>> Hi,
>>
>> glibc 2.9 implement parallel IPv4/IPv6 DNS lookup. This caused lots of
>> trouble
>> in all kind of implementations, so all major Linux distributions removed
>> _nss_dns_gethostbyname4_r in their glibc version, except for Debian Squeeze,
>> see also "options single-request" for more information.
>>
>> Normally parallel DNS lookups works fine, first packet is received and
>> forwarded, so conntrack is confirmed before second packet is received.
>>
>> However in combination with NFQUEUE, the second DNS requests is
>> received while the first one is still in the queue and both DNS requests
>> have an unconfirmed conntrack. So the second one will be dropped
>> in nf_conntrack_confirm, which results in an DNS timeout and retransmit.
>>
>> Can be reproduced with: adnshost yahoo.com google.com
>>
>> My first idea was to re-lookup the conntrack in nf_conntrack_confirm,
>> but at that time the seconds request was already NATed. So I moved
>> that code to nf_nat_fn(). Of course this only works if nat is loaded...
>>
>> Any comments or ideas, how to address this problem?
>
> It seems that you queue packets in the middle of conntrack. Beside
> NFQUEUE, IMQ may causes the same problem. I think you'd better queue
> packets before conntrack, raw table? Or lookup the conntrack again
> after packets are reinjected.
>
--
Ulrich Weber | uweber@astaro.com | Software Engineer
Astaro GmbH & Co. KG | www.astaro.com | Phone +49-721-25516-0 | Fax –200
An der RaumFabrik 33a | 76227 Karlsruhe | Germany
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2010-11-22 12:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-19 9:58 [RFC PATCH] nfqueue: nf_conntrack_confirm race condition Ulrich Weber
2010-11-20 6:49 ` Changli Gao
2010-11-22 12:34 ` Ulrich Weber [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CEA636C.80904@astaro.com \
--to=uweber@astaro.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=xiaosuo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.