Re: Netfilter: kernel panic with REDIRECT target. (2.6.23 and 2.6.23.8)

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Tue, Nov 20, 2007 at 01:24:17PM +0100, Patrick McHardy (kaber@trash.net) wrote:
> Patrick McHardy wrote:
> >Evgeniy Polyakov wrote:
> >>>>>Ok, let's try it hard way.
> >>>>>Please check attached patch and tell if it helped (it will produce
> >>>>>some debug though).
> >>>>With both patches applied - one Patrick showed and this one.
> >>>>  
> >>>Now works, with this in dmesg
> >>>
> >>>conntrack: ea94159c, new: ead4d7c4, old: ead4d7d0, ct: 00000000.
> >>
> >>David (Miller :), please apply attached patch, which also needed to fix
> >>netfilter connection tracking bug.
> >>When connection tracking entry (nf_conn) is about to copy itself it can
> >>have some of its extension users (like nat) as being already freed and
> >>thus not required to be copied.
> >>Frankly saying, it can be not the correct fix, but from code observation
> >>and test, perfomed by David <david@unsolicited.net> it is.
> >
> >I also don't believe this can be correct, let me look into this
> >first.
> 
> 
> I now understand whats happening:
> 
> - new connection is allocated without helper
> - connection is REDIRECTed to localhost
> - nf_nat_setup_info adds NAT extension, but doesn't initialize it yet
> - nf_conntrack_alter_reply performs a helper lookup based on the
>   new tuple, finds the SIP helper and allocates a helper extension,
>   causing reallocation because of too little space
> - nf_nat_move_storage is called with the uninitialized nat extension
> 
> So your fix is entirely correct, thanks a lot :)

It is always better to check my third eye revelations :)
Thanks for checking it.

-- 
	Evgeniy Polyakov