linux-kernel - Re: Soft lockup on shutdown in nf_ct_iterate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 25 Feb 2007 19:38:13 +0100
From:	Martin Josefsson <gandalf@...g.westbo.se>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	Chuck Ebbert <cebbert@...hat.com>,
	netfilter-devel@...ts.netfilter.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()

On Sun, 2007-02-25 at 18:31 +0100, Patrick McHardy wrote:

> [NETFILTER]: conntrack: fix {nf,ip}_ct_iterate_cleanup endless loops
> 
> {nf,ip}_ct_iterate_cleanup iterate over the unconfirmed list for cleaning
> up conntrack entries, which is wrong for multiple reasons:
> 
> - unconfirmed entries can not be killed manually, which means we might
>   iterate forever without making forward progress.
> 
>   This can happen in combination with the conntrack event cache, which
>   holds a reference to the conntrack entry, which is only released when
>   the packet makes it all the way through the stack or a different
>   packet is handled.
>
> - taking references to an unconfirmed entry and using it outside the
>   locked section doesn't work, the list entries are not refcounted and
>   another CPU might already be waiting to destroy the entry
> 
> Split ip_ct_iterate_cleanup in ip_ct_iterate, which iterates over both
> confirmed and unconfirmed entries, but doesn't attempt to kill them,
> and ip_ct_cleanup, which makes sure no unconfirmed entries exist by
> calling synchronize_net() prior to walking the conntrack hash.

What about this case:

1. Conntrack entry is created and placed on the unconfirmed list
2. The event cache bumps the refcount of the conntrack entry
3. module removal of ip_conntrack unregisters all hooks
4. packet is dropped by an iptables rule
5. packet is freed but we still have a refcount on the conntrack entry

Now there's no way to get that refcount to decrease as that only happens
when the event cache receives another packet or the current packet makes
it through the stack as you wrote above. And neither of this will happen
since we unregistered the hooks providing the packets and dropped the
packet.

I ran into this case a while ago during stresstesting and rewrote the
event cache to not increase the refcount, but this has the drawback that
events caused by dropped packets won't be reported. This may not be a
good thing...

Old patch can be found here:
http://performance.netfilter.org/patches/nf_conntrack_ecache-fix

-- 
/Martin

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)