netdev - Re: [PATCH] netns: do not leak net

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] [day] [month] [year] [list]

Date:	Wed, 18 Apr 2012 00:05:44 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	ebiederm@...ssion.com
Cc:	ja@....bg, netdev@...r.kernel.org
Subject: Re: [PATCH] netns: do not leak net_generic data on failed init

From: ebiederm@...ssion.com (Eric W. Biederman)
Date: Tue, 17 Apr 2012 21:01:28 -0700

> Julian Anastasov <ja@....bg> writes:
> 
>> 	ops_init should free the net_generic data on
>> init failure and __register_pernet_operations should not
>> call ops_free when NET_NS is not enabled.
> 
> The subject is good.
> 
> There is most definitely a leak with us not freeing the net_generic data
> on ops_init failure.  Having ops_init just take care of it seems like
> the logical place as it makes for simple analysis.
> 
> The bit about __register_pernet_operations should not call ops_free when
> NET_NS is not enabled is a bad comment.  We just need to move the
> ops_free into ops_init on failure, which is what your patch does.
> 
> Without your patch the only caller of ops_init that doesn't leak today
> is __register_pernet_operations in !CONFIG_NET_NS, precisely because
> it does that ops_free.
> 
> Now all of that said I have just read through everything and
> patch cleanly fixes a rare but real memory leak, and leaves
> the code in better state then it is today.
> 
> David please apply this patch.
> 
> Reviewed-by: "Eric W. Biederman" <ebiederm@...ssion.com>

Done, thanks Eric.
--
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