mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: jiayuan.chen@linux.dev
Cc: netdev@vger.kernel.org, dsahern@kernel.org, idosch@nvidia.com,
	davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org,
	pabeni@redhat.com, horms@kernel.org, pablo@netfilter.org,
	fw@strlen.de, phil@nwl.cc, razor@blackwall.org,
	paul@paul-moore.com, matttbe@kernel.org, martineau@kernel.org,
	geliang@kernel.org, ja@ssi.bg, achender@kernel.org,
	marcelo.leitner@gmail.com, lucien.xin@gmail.com,
	alibuda@linux.alibaba.com, dust.li@linux.alibaba.com,
	sidraya@linux.ibm.com, mjambigi@linux.ibm.com,
	tonylu@linux.alibaba.com, guwen@linux.alibaba.com,
	linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	coreteam@netfilter.org, bridge@lists.linux.dev,
	linux-security-module@vger.kernel.org, mptcp@lists.linux.dev,
	lvs-devel@vger.kernel.org, linux-rdma@vger.kernel.org,
	rds-devel@oss.oracle.com, linux-sctp@vger.kernel.org,
	linux-s390@vger.kernel.org
Subject: Re: [PATCH net-next 14/14] netfilter: cttimeout: annotate data-races around the default timeouts
Date: Tue, 10 Nov 2026 05:53:27 +0000	[thread overview]
Message-ID: <179429000729.994134.16108041301574145842@kernel.org> (raw)
In-Reply-To: <20261109025425.328445-15-jiayuan.chen@linux.dev>

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] A concurrent sysctl write to a default conntrack timeout can
  still be silently undone.

--

netfilter: cttimeout: annotate data-races around the default timeouts

This commit changes the l4proto nlattr_to_obj() and obj_to_nlattr()
timeout callbacks to use WRITE_ONCE() and READ_ONCE() instead of plain
accesses. It targets races between cttimeout_default_set() and
cttimeout_default_get(), the conntrack packet path, and the
nf_conntrack_*_timeout* sysctl handlers, which all touch the same
per-netns default timeout arrays.

> diff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c
> index 99eedaa2b1183..777b21da3bcff 100644
> --- a/net/netfilter/nf_conntrack_proto_udp.c
> +++ b/net/netfilter/nf_conntrack_proto_udp.c
> @@ -155,16 +155,16 @@ static int udp_timeout_nlattr_to_obj(struct nlattr *tb[],
>  		timeouts = un->timeouts;
>  
>  	/* set default timeouts for UDP. */
> -	timeouts[UDP_CT_UNREPLIED] = un->timeouts[UDP_CT_UNREPLIED];
> -	timeouts[UDP_CT_REPLIED] = un->timeouts[UDP_CT_REPLIED];
> +	WRITE_ONCE(timeouts[UDP_CT_UNREPLIED], READ_ONCE(un->timeouts[UDP_CT_UNREPLIED]));
> +	WRITE_ONCE(timeouts[UDP_CT_REPLIED], READ_ONCE(un->timeouts[UDP_CT_REPLIED]));

[Severity: Medium]

Can a concurrent sysctl write still be lost here?

cttimeout_default_set() passes a NULL destination:

net/netfilter/nfnetlink_cttimeout.c:cttimeout_default_set() {
    ...
	ret = ctnl_timeout_parse_policy(NULL, l4proto, info->net,
					cda[CTA_TIMEOUT_DATA]);
    ...
}

So udp_timeout_nlattr_to_obj() sets timeouts to un->timeouts, and the
default copy turns into a self-copy of the live per-netns array:

	WRITE_ONCE(un->timeouts[UDP_CT_REPLIED],
		   READ_ONCE(un->timeouts[UDP_CT_REPLIED]));

That is still a separate load and store. The sysctl handler writes the
same field through proc_dointvec_jiffies() and does not take the nfnl
mutex. Take a request that carries only CTA_TIMEOUT_UDP_UNREPLIED, sent
while nf_conntrack_udp_timeout_stream is being written:

CPU0 (IPCTNL_MSG_TIMEOUT_DEFAULT_SET)
  old = READ_ONCE(un->timeouts[UDP_CT_REPLIED])

CPU1 (sysctl write)
  WRITE_ONCE(un->timeouts[UDP_CT_REPLIED], new)

CPU0
  WRITE_ONCE(un->timeouts[UDP_CT_REPLIED], old)

The sysctl value gets reverted, even though the netlink request never
named that attribute.

The second KCSAN splat in the commit message (proc_int_u2k_conv_uop vs
udp_timeout_nlattr_to_obj) comes from this access pair. Once both sides
are marked, KCSAN stops reporting it, but the update can still be lost.

The same self-copy happens in these places:

  tcp_timeout_nlattr_to_obj(), where timeouts = tn->timeouts and the
  loop covers all TCP_CONNTRACK_TIMEOUT_MAX entries
  sctp_timeout_nlattr_to_obj(), where timeouts = sn->timeouts
  gre_timeout_nlattr_to_obj(), where timeouts = gre_get_timeouts(net)
  the else branch of generic_timeout_nlattr_to_obj(), when timeout is
  &gn->timeout
  the else branch of icmpv6_timeout_nlattr_to_obj(), when timeout
  falls back to icmpv6_get_timeouts(net)

When the destination already points at the per-netns array, could the
default copy be skipped, so that fields missing from the request are
never stored?

>  
>  	if (tb[CTA_TIMEOUT_UDP_UNREPLIED]) {
> -		timeouts[UDP_CT_UNREPLIED] =
> -			ntohl(nla_get_be32(tb[CTA_TIMEOUT_UDP_UNREPLIED])) * HZ;
> +		WRITE_ONCE(timeouts[UDP_CT_UNREPLIED],
> +			   ntohl(nla_get_be32(tb[CTA_TIMEOUT_UDP_UNREPLIED])) * HZ);
>  	}

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261109025425.328445-1-jiayuan.chen%40linux.dev

  reply	other threads:[~2026-11-10  5:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09  2:51 [PATCH net-next 00/14] net: annotate data-races around sysctl knobs Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 01/14] ipv4: annotate data-races around ip_rt_* sysctls Jiayuan Chen
2026-11-10  5:53   ` netdev-bot+sashiko
2026-11-09  2:52 ` [PATCH net-next 02/14] inet: frags: annotate data-races around fqdir->timeout and fqdir->max_dist Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 03/14] ipv6: annotate data-races around addrconf sysctls Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 04/14] ipv6: annotate data-races around icmpv6 reply sysctls Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 05/14] calipso: annotate data-races around cache sysctls Jiayuan Chen
2026-11-10  5:53   ` netdev-bot+sashiko
2026-11-09  2:52 ` [PATCH net-next 06/14] sctp: annotate data-races around sctp sysctls Jiayuan Chen
2026-11-10  5:53   ` netdev-bot+sashiko
2026-11-09  2:52 ` [PATCH net-next 07/14] mptcp: annotate data-races around pernet sysctls Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 08/14] rds: annotate data-races around core rds sysctls Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 09/14] netfilter: conntrack: annotate data-races around conntrack sysctls Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 10/14] netfilter: bridge: annotate data-races around br_netfilter and nf_log sysctls Jiayuan Chen
2026-11-10  5:53   ` netdev-bot+sashiko
2026-11-09  2:52 ` [PATCH net-next 11/14] ipvs: annotate data-races around lblc_expiration and lblcr_expiration Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 12/14] net/smc: annotate data-races around smc sysctls Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 13/14] netfilter: conntrack: annotate data-races around timeout and tcp sysctls Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 14/14] netfilter: cttimeout: annotate data-races around the default timeouts Jiayuan Chen
2026-11-10  5:53   ` netdev-bot+sashiko [this message]
2026-11-09  3:11 ` [PATCH net-next 00/14] net: annotate data-races around sysctl knobs Jason Xing
2026-11-09  3:33   ` Jiayuan Chen
2026-11-09  6:52     ` Jason Xing

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=179429000729.994134.16108041301574145842@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=achender@kernel.org \
    --cc=alibuda@linux.alibaba.com \
    --cc=bridge@lists.linux.dev \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=dust.li@linux.alibaba.com \
    --cc=edumazet@kernel.org \
    --cc=fw@strlen.de \
    --cc=geliang@kernel.org \
    --cc=guwen@linux.alibaba.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=ja@ssi.bg \
    --cc=jiayuan.chen@linux.dev \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=lvs-devel@vger.kernel.org \
    --cc=marcelo.leitner@gmail.com \
    --cc=martineau@kernel.org \
    --cc=matttbe@kernel.org \
    --cc=mjambigi@linux.ibm.com \
    --cc=mptcp@lists.linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    --cc=paul@paul-moore.com \
    --cc=phil@nwl.cc \
    --cc=razor@blackwall.org \
    --cc=rds-devel@oss.oracle.com \
    --cc=sidraya@linux.ibm.com \
    --cc=tonylu@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®