netdev - Re: [PATCH 19/19] netfilter: gre: fix resource leak when unregister gre proto

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]

Message-ID: <50EA2489.3070309@cn.fujitsu.com>
Date:	Mon, 07 Jan 2013 09:27:37 +0800
From:	Gao feng <gaofeng@...fujitsu.com>
To:	Pablo Neira Ayuso <pablo@...filter.org>
CC:	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
	canqunzhang@...il.com, kaber@...sh.net, ebiederm@...ssion.com
Subject: Re: [PATCH 19/19] netfilter: gre: fix resource leak when unregister
 gre proto

Hi Pablo,

On 01/05/13 11:50, Pablo Neira Ayuso wrote:
> Hi Gao,
> 
> On Fri, Dec 28, 2012 at 10:36:46AM +0800, Gao feng wrote:
>> Currectly we unregister proto before all conntrack entries of
>> this proto being destroyed. so in function destroy_conntrack
>> we can't find proper l4proto to call l4proto->destroy.
>> this will cause resource leak.
> 
> Good catch.
> 
> But better to remove the entries before unregistering the protocol
> tracker, so l4proto->destroy is always called.
> 

I think the reason we unregister proto before remove all entries
is to avoid new entry for this protocol being created.

If we remove all contrack entries before unregistration, there maybe
some new entries being created between nf_ct_iterate_cleanup and
nf_conntrack_l4proto_unregister_net.this will cause some terrible things.

SO I think we should make proto unavailable first,remove all entries next,
and remove proto from nf_ct_protos arrays finally.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html