Re: [PATCH] Prevent crash on ip_conntrack removal

[Patrick McHardy <kaber@trash.net>]

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.

Regards
Patrick