From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Subject: Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I Date: Fri, 04 Nov 2005 19:12:48 +0100 Message-ID: <436BA4A0.5040204@eurodev.net> References: <436A6B39.3080508@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org Return-path: To: Krzysztof Oledzki In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Krzysztof Oledzki wrote: > On Thu, 3 Nov 2005, Pablo Neira wrote: > >> Krzysztof Oledzki wrote: >> >>> # conntrack -I --orig-src 1.2.3.4 --orig-dst 1.2.3.5 --reply-src 2.3.4.5 >>> --reply-dst 2.3.4.5 -p tcp --orig-port-src 1 --orig-port-dst 2 >>> --reply-port-src 3 --reply-port-dst 4 -t 32323 -u ASSURED >> >> >> --state option is missing: Unfortunately conntrack forgot to check it >> that such parameter was missing and ctnetlink didn't do that check >> either. That's why it resulted in an oops :( >> >> I've just applied a patch for conntrack, refresh your working copy. So >> you won't be able to reproduce that oops anymore. >> >> Anyway I'll send a patch for ctnetlink, that checking must be done in >> kernel space as well. > > Thank you. When are you going to release the 1.0 version? How much time > I have left for testing? ;) Good question. I wanted to do it before 2.6.14, but it seems that time run up. So my proposed alternative is doing it as soon as there are no known bugs in ctnetlink, I don't want people complaining about crashing kernels because of this stuff *sigh*. And of course, once there are no complains about conntrack/libnetfilter_conntrack for some days at the same time. -- Pablo