linux-kernel - Re: [PATCH nf-next v2] netfilter: conntrack: Add missing modification about data-race around ct->timeout

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] [day] [month] [year] [list]

Message-ID: <aR23QWKZvF4gdCGU@strlen.de>
Date: Wed, 19 Nov 2025 13:25:37 +0100
From: Florian Westphal <fw@...len.de>
To: Chenguang Zhao <zhaochenguang@...inos.cn>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
	Jozsef Kadlecsik <kadlec@...filter.org>, Phil Sutter <phil@....cc>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>, netfilter-devel@...r.kernel.org,
	coreteam@...filter.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH nf-next v2] netfilter: conntrack: Add missing
 modification about data-race around ct->timeout

Chenguang Zhao <zhaochenguang@...inos.cn> wrote:
> struct nf_conn)->timeout can be read/written locklessly,
> add READ_ONCE()/WRITE_ONCE() to prevent load/store tearing.

Do you have a KCSAN splat or similar?

> The patch 'commit 802a7dc5cf1b ("netfilter: conntrack: annotate
> data-races around ct->timeout")'fixed it, but there was a
> missing part that this patch completes it.

I'm no longer sure this was missing.

> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index 344f88295976..df4426adc9c8 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -1297,7 +1297,7 @@ __nf_conntrack_confirm(struct sk_buff *skb)
>  	/* Timeout is relative to confirmation time, not original
>  	   setting time, otherwise we'd get timer wrap in
>  	   weird delay cases. */
> -	ct->timeout += nfct_time_stamp;
> +	WRITE_ONCE(ct->timeout, READ_ONCE(ct->timeout) + nfct_time_stamp);

Here we hold the bucket insert locks for ct, so I don't see
how we can have concurrent modification here.