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: <4A3A5599.4080906@trash.net>
Date:	Thu, 18 Jun 2009 16:56:25 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Eric Dumazet <dada1@...mosbay.com>
CC:	Ingo Molnar <mingo@...e.hu>, David Miller <davem@...emloft.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Pablo Neira Ayuso <pablo@...filter.org>
Subject: Re: [bug] __nf_ct_refresh_acct(): WARNING: at lib/list_debug.c:30
 __list_add+0x7d/0xad()

Patrick McHardy wrote:
> Eric Dumazet wrote:
>>> a test-box still triggered this crash overnight:
>>>
>>> [  252.433471] ------------[ cut here ]------------
>>> [  252.436031] WARNING: at lib/list_debug.c:30 __list_add+0x95/0xa0()
>>> ...
>>> With your patch (repeated below) applied. Is Patrick's alternative 
>>> patch supposed to fix something that yours does not?
>>
>> Hmm, not really, Patrick patch should fix same problem, but without 
>> extra locking
>> as mine.
>>
>> This new stack trace is somewhat different, as corruption is detected 
>> in the add_timer()
>> call in __nf_conntrack_confirm()
>>
>> So there is another problem. CCed Pablo Neira Ayuso who added some stuff
>> in netfilter and timeout logic recently.
> 
> That timeout logic shouldn't be relevant in this case, its only
> activated when netlink event delivery is used, a userspace process
> is actually listening and it has the socket marked for reliable
> delivery.
> 
> I think its still the same problem, the detection is just noticed
> at a different point.

I can't find anything wrong with the conntrack timer use itself.
Since its the timer base that is corrupted, its possible that
something else is using timers incorrectly and conntrack just
happens to hit the problem afterwards, but it seems rather
unlikely since the first backtrace originated in a network driver,
the second one in the socket layer.

But I've noticed a different problem, the lockless lookup might
incorrectly return an conntrack entry that is supposed to be
invisible. This can happen because we only check for equal tuples
and !atomic_inc_not_zero(refcnt), but the conntrack can be removed
from the lists and still have references to it. It should never
have an active timer at that point however, so all following
mod_timer_pending() calls *should* do nothing unless I'm missing
something.

Ingo, could you please try whether this patch (combined with the
last one) makes any difference? Enabling CONFIG_NETFILTER_DEBUG
could also help.



View attachment "x" of type "text/plain" (877 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ