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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4742D1F1.20805@trash.net>
Date:	Tue, 20 Nov 2007 13:24:17 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
CC:	David <david@...olicited.net>,
	Ismail Dönmez <ismail@...dus.org.tr>,
	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: Netfilter: kernel panic with REDIRECT target. (2.6.23 and 2.6.23.8)

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@...olicited.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 :)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html