netdev - Re: Oops with latest (netfilter) nf-next tree, when unloading iptable

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:	Thu, 20 Sep 2012 08:57:04 +0200 (MEST)
From:	Patrick McHardy <kaber@...sh.net>
To:	Jesper Dangaard Brouer <brouer@...hat.com>
cc:	Pablo Neira Ayuso <pablo@...monks.org>,
	Florian Westphal <fw@...len.de>,
	netfilter-devel <netfilter-devel@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>, yongjun_wei@...ndmicro.com.cn
Subject: Re: Oops with latest (netfilter) nf-next tree, when unloading
 iptable_nat

On Wed, 19 Sep 2012, Jesper Dangaard Brouer wrote:

> On Fri, 2012-09-14 at 15:15 +0200, Patrick McHardy wrote:
>> On Fri, 14 Sep 2012, Pablo Neira Ayuso wrote:
>>
> [...cut...]
>>>> Patrick, any other idea?
>>>
> [...cut...]
>>>>
>>> We can add nf_nat_iterate_cleanup that can iterate over the NAT
>>> hashtable to replace current usage of nf_ct_iterate_cleanup.
>>
>> Lets just bail out when IPS_SRC_NAT_DONE is not set, that should also fix
>> it. Could you try this patch please?
>
> On Fri, 2012-09-14 at 15:15 +0200, Patrick McHardy wrote:
> diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
>> index 29d4452..8b5d220 100644
>> --- a/net/netfilter/nf_nat_core.c
>> +++ b/net/netfilter/nf_nat_core.c
>> @@ -481,6 +481,8 @@ static int nf_nat_proto_clean(struct nf_conn *i,
> void *data)
>>
>>         if (!nat)
>>                 return 0;
>> +       if (!(i->status & IPS_SRC_NAT_DONE))
>> +               return 0;
>>         if ((clean->l3proto && nf_ct_l3num(i) != clean->l3proto) ||
>>             (clean->l4proto && nf_ct_protonum(i) != clean->l4proto))
>>                 return 0;
>>
>
> No it does not work :-(

Ok I think I understand the problem now, we're invoking the NAT cleanup
callback twice with clean->hash = true, once for each direction of the
conntrack.

Does this patch fix the problem?
View attachment "nat-oops.diff" of type "TEXT/PLAIN" (4200 bytes)