linux-kernel - Re: netfilter: nf_conntrack: there maybe a bug in __nf_conntrack_confirm, when it race against get_next

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: <20141028094612.GA14392@breakpoint.cc>
Date:	Tue, 28 Oct 2014 10:46:12 +0100
From:	Florian Westphal <fw@...len.de>
To:	billbonaparte <programme110@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	'Netfilter Developer Mailing List' 
	<netfilter-devel@...r.kernel.org>,
	'Pablo Neira Ayuso' <pablo@...filter.org>,
	'Patrick McHardy' <kaber@...sh.net>, kadlec@...ckhole.kfki.hu,
	davem@...emloft.net, 'Changli Gao' <xiaosuo@...il.com>,
	'Jesper Dangaard Brouer' <brouer@...hat.com>,
	'Andrey Vagin' <avagin@...nvz.org>
Subject: Re: netfilter: nf_conntrack: there maybe a bug in
 __nf_conntrack_confirm, when it race against get_next_corpse

billbonaparte <programme110@...il.com> wrote:
> 	In function __nf_conntrack_confirm, we check the conntrack if it was
> alreay dead, before insert it into hash-table. 
> 	we do this because if we insert an already 'dead' hash,  it will
> block further use of that particular connection.
> 	but we don't do that right.

Correct.  This is broken since the central spin lock removal, since
nf_conntrack_lock no longer protects both get_next_corpse and
conntrack_confirm.

Please send a patch, moving dying check after removal of conntrack from
the percpu list, and add

Fixes: 93bb0ceb75be2 (netfilter: conntrack: remove central spinlock nf_conntrack_lock)

tag to patch.

> 	The above case reveal two problems:
> 	1. we may insert a dead conntrack to hash-table, it will block
> further use of that particular connection.

Yes.

> 	2. operation on ct->status should be atomic, because it race aginst
> get_next_corpse.

Alternatively we could also get rid of the unconfirmed list handling in
get_next_corpse, it looks to me as if its simply not worth the trouble
to also caring about unconfirmed lists.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/