From: Patrick McHardy <kaber@trash.net>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Netfilter development mailing list <netfilter-devel@lists.netfilter.org>
Subject: Re: [PATCH] Fix conntrack iteration.
Date: Sat, 25 Dec 2004 15:32:24 +0100 [thread overview]
Message-ID: <41CD79F8.5060003@trash.net> (raw)
In-Reply-To: <1103888157.4000.2.camel@localhost.localdomain>
Rusty Russell wrote:
> Found this bug while searching for another. Potential crash on unload
> (unlikely though, unless packets are queued).
>
> Name: Fix ip_ct_selective_cleanup(), and rename ip_ct_iterate_cleanup()
> Status: Tested under nfsim
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
> Several places use ip_ct_selective_cleanup() as a general iterator,
> which it was not intended for (it takes a const ip_conntrack *). So
> rename it, and make it take a non-const argument.
>
> Also, it missed unconfirmed connections, which aren't in the hash
> table. This introduces a potential problem for users which expect to
> iterate all connections (such as the helper deletion code). So keep a
> linked list of unconfirmed connections as well.
>
> Index: linux-2.6.10-rc3-bk16-Netfilter/net/ipv4/netfilter/ip_nat_core.c
> ===================================================================
> --- linux-2.6.10-rc3-bk16-Netfilter.orig/net/ipv4/netfilter/ip_nat_core.c 2004-12-24 22:11:43.372205240 +1100
> +++ linux-2.6.10-rc3-bk16-Netfilter/net/ipv4/netfilter/ip_nat_core.c 2004-12-24 22:15:18.980427808 +1100
> @@ -298,9 +299,13 @@
> ip_conntrack_destroyed(ct);
>
> WRITE_LOCK(&ip_conntrack_lock);
> - /* Make sure don't leave any orphaned expectations lying around */
> - if (ct->expecting)
> - remove_expectations(ct, 1);
> + BUG_ON(ct->expecting);
This doesn't look right. The call to remove_expectations was
added to deal with the TFTP helper registering expectations
for unconfirmed connections.
Testcase from Phil Oester, who tracked down the problem:
--------
on a:
iptables -I INPUT -p udp --dport 69 -j DROP
on b:
tftp -c get a:foo
The expect is setup by the tftp helper, but the master conntrack is not
confirmed. Instead, the master is immediately sent to
destroy_conntrack. Whoops! We've now got an orphaned expectation which
will not go away (ever!).
--------
Regards
Patrick
next prev parent reply other threads:[~2004-12-25 14:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-24 11:35 [PATCH] Fix conntrack iteration Rusty Russell
2004-12-25 14:32 ` Patrick McHardy [this message]
2004-12-28 1:22 ` Rusty Russell
2004-12-28 1:45 ` Rusty Russell
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=41CD79F8.5060003@trash.net \
--to=kaber@trash.net \
--cc=netfilter-devel@lists.netfilter.org \
--cc=rusty@rustcorp.com.au \
/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.