[Top] [All Lists]

Re: [PATCH] Prevent crash on ip_conntrack removal

To: David Stevens <dlstevens@xxxxxxxxxx>
Subject: Re: [PATCH] Prevent crash on ip_conntrack removal
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Tue, 24 Aug 2004 02:45:41 +0200
Cc: "David S. Miller" <davem@xxxxxxxxxx>, laforge@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx, netdev-bounce@xxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx, okir@xxxxxxx
In-reply-to: <OF4320C747.75C5E93A-ON88256EF9.00744FBA-88256EF9.00750996@xxxxxxxxxx>
References: <OF4320C747.75C5E93A-ON88256EF9.00744FBA-88256EF9.00750996@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5
David Stevens wrote:

BTW, since some of the frags (esp. the one that triggers the problem)
are added post-routing, a valid dst is available. It just isn't the first
frag in the particular scenario.

So, one solution would be to set skb->dst for the head (if NULL)  based
on a non-null fragment skb->dst. I believe that would prevent the problem
case without dropping the fragment, since it'll be processed post-routing
only if one of the frags is.
The fragments which jumped from PRE_ROUTING to ip_local_deliver will miss
ip options processing.

When I was looking at it, I wondered if conntrack really has a need to
reassemble itself, though. Couldn't it let IP do the reassembling and
just ignore offset != 0 frags? The offset==0 frags will have enough
protocol header to identify by port (a requirement for ICMP). But I don't
know this code well enough to know if conntrack does actually need
to reassemble for some good reason. Superficially, I wouldn't think
there'd be a reason for it.
The NAT code needs to handle all fragments, so they can't be skipped.
Handling fragments in conntrack and NAT would be possible without helpers,
but to scan for patterns in fragments you need state for each fragmented
packet for each connection.


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