Re: memory leak related to bridging, conntrack and frags in 2.6.0

Bart De Schuymer <[email protected]>
Newsgroups gmane.linux.network.bridge.ebtables.devel,gmane.linux.kernel,gmane.comp.security.firewalls.netfilter.devel
Message-ID <[email protected]>
On Friday 12 December 2003 20:55, Steve Hill wrote:
> Sorry for the cross-post - I thought this would be of interest to all the
> lists and also wasn't sure where the best people to help hang out.

The right mailing list for this is [email protected]

> With both conntrack and bridging turned on in the 2.6.0test11 kernel,
> sending fragmented packets over the bridge reveals a memory leak
> (specifically, forwarding packets from any interface to a bridge).  The
> memory that is leaking seems to be being allocated on line 299 on
> net/bridge/br_netfilter.c:
>
>         if ((nf_bridge = nf_bridge_alloc(skb)) == NULL)
>                 return NF_DROP;

Thanks for the good diagnose.

> Only the first fragment gets freed later on.
>
> The patch attached fixes the problem by freeing nf_bridge when the
> packets are defragmented, however I am sure this is not the right place
> to do this.  Where would the skb's for the fragments usually get freed?

I believe they are freed in skbuff.c::skb_release_data().

I think the place where you've put the fix doesn't cover all cases. If 
ip_frag_destroy() is called, there will still be a memory leak. So I think 
the right place for this is in skb_release_data. But consulting with the 
netdev list seems appropriate :)

You can change
+		if (fp->nf_bridge) {
+			nf_bridge_put(fp->nf_bridge);
+			fp->nf_bridge = NULL;
+		};
into
+		nf_bridge_put(fp->nf_bridge);

cheers,
Bart



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.