netdev
[Top] [All Lists]

Re: [PATCH] Prevent crash on ip_conntrack removal

To: Olaf Kirch <okir@xxxxxxx>
Subject: Re: [PATCH] Prevent crash on ip_conntrack removal
From: Harald Welte <laforge@xxxxxxxxxxxxx>
Date: Thu, 19 Aug 2004 12:11:59 +0200
Cc: netdev@xxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx, David Miller <davem@xxxxxxxxxx>
In-reply-to: <20040818091352.GB6507@xxxxxxx>
Mail-followup-to: Harald Welte <laforge@xxxxxxxxxxxxx>, Olaf Kirch <okir@xxxxxxx>, netdev@xxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx, David Miller <davem@xxxxxxxxxx>
References: <20040818091352.GB6507@xxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
On Wed, Aug 18, 2004 at 11:13:52AM +0200, Olaf Kirch wrote:
> Hi,
> 
> here's a patch that keeps us from crashing on removal of ip_conntrack.
> This problem came up during IBM's testing of SLES.

Thanks for this detailed bugreport and fix.

> I'm not sure if this issue has been submitted already.

Not that I'm aware of.

> To fix this, the patch below simply drops such skbs. A different fix
> could be to change the conntrack module to flush out all unassembled
> fragments when unloaded; an alternative patch for this is attached as
> well (this one is completely untested).

Since I don't want to put any more conntrack-specific code into the core
network stack, I'd rather go for the 'alternative patch'.

I'm not sure whether it's worth the effort to combine the two, i.e. only
flush entries with skb->dst == NULL.

But especially since module unloading is EXPERIMENTAL anyway, I think
it's ok when we completely flush the fragemnt queue.

Dave, is this fine with you?  What solution would you prefer?

> Cheers
> Olaf
-- 
- Harald Welte <laforge@xxxxxxxxxxxxx>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>