netdev - Re: Possible race condition in conntracking

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: <497F08C4.90705@trash.net>
Date:	Tue, 27 Jan 2009 14:14:44 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Tobias Klausmann <klausman@...warzvogel.de>
CC:	netdev@...r.kernel.org,
	Netfilter Development Mailinglist 
	<netfilter-devel@...r.kernel.org>
Subject: Re: Possible race condition in conntracking

Tobias Klausmann wrote:
> Hi! 
> 
> (I've now subscribed to netdev@, so no more CCs to me are necessary).
> 
> On Tue, 27 Jan 2009, Patrick McHardy wrote:
>> That sounds plausible, but we only discard the new conntrack
>> entry on clashes. The packet should be fine, unless you drop
>> INVALID packets in your ruleset.
> 
> The ruleset currently does not contain any rules regarding
> INVALID. Consequently, we opted for the TRACE approach.
> 
>> Try tracing the packet using the TRACE target. That should show
>> whether it really disappears within netfilter and where.
> 
> I've removed the irrelevant fields like TTL, PREC etc and timing
> info from syslog from the trace after making sure nothing funky
> was going on there.
> 
> Apart from the ID field, I ended up with two identical traces.
> 
> So, as far as rule-matching is concerned, the two packets are
> handled identically. Whatever happens after this:
> 
> Jan 27 11:00:39 fw2 kernel: TRACE: nat:POSTROUTING:policy:3 IN=
> OUT=eth2.188 SRC=194.97.7.116 DST=194.97.3.83 LEN=66 TOS=0x00
> PREC=0x00 TTL=63 ID=46964 DF PROTO=UDP SPT=53452 DPT=53 LEN=46 
> 
> is making this very packet go away. The policy of nat/PR is
> ACCEPT.

This just means it passed through the last table/chain. The
only one following is conntrack confirmation.

Damn it :) I just noticed, we do indeed drop packets from
duplicate new connections in conntrack confirmation.

You should see the insert_failed conntrack counter show this
(/proc/net/stat/nf_conntrack).
--
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