From: Simon Horman <horms@kernel.org>
To: netdev-bot+sashiko@kernel.org
Cc: jiayuan.chen@linux.dev, netdev@vger.kernel.org,
dsahern@kernel.org, idosch@nvidia.com, davem@davemloft.net,
edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com,
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 06/14] sctp: annotate data-races around sctp sysctls
Date: Fri, 13 Nov 2026 17:14:52 +0000 [thread overview]
Message-ID: <20261113171452.GQ18859@horms.kernel.org> (raw)
In-Reply-To: <179429000207.994134.10637780638316929795@kernel.org>
On Tue, Nov 10, 2026 at 05:53:22AM +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider.
>
> Critical: 0 · High: 1 · Medium: 0 · 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).
>
> - [High] The fix is incomplete inside the same sysctl handlers it
> changes.
>
> --
>
> sctp: annotate data-races around sctp sysctls
>
> This commit adds READ_ONCE() to readers of many per-netns sctp sysctl
> fields. It also converts the plain stores in the rto_min, rto_max,
> udp_port, probe_interval, auth_enable and cookie_hmac_alg handlers to
> WRITE_ONCE().
>
> > diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
> > index 2b94c211427de..8a84ae3272d24 100644
> > --- a/net/sctp/sysctl.c
> > +++ b/net/sctp/sysctl.c
> > @@ -402,11 +402,11 @@ static int proc_sctp_do_hmac_alg(const struct ctl_table *ctl, int write,
> > if (ret)
> > return ret;
> > if (!strcmp(tmp, "sha256")) {
> > - net->sctp.cookie_auth_enable = 1;
> > + WRITE_ONCE(net->sctp.cookie_auth_enable, 1);
> > return 0;
> > }
> > if (!strcmp(tmp, "none")) {
> > - net->sctp.cookie_auth_enable = 0;
> > + WRITE_ONCE(net->sctp.cookie_auth_enable, 0);
> > return 0;
> > }
> > return -EINVAL;
> > @@ -441,7 +441,7 @@ static int proc_sctp_do_rto_min(const struct ctl_table *ctl, int write,
> > if (new_value > max || new_value < min)
> > return -EINVAL;
> >
> > - net->sctp.rto_min = new_value;
> > + WRITE_ONCE(net->sctp.rto_min, new_value);
> > }
> >
> > return ret;
> > @@ -469,7 +469,7 @@ static int proc_sctp_do_rto_max(const struct ctl_table *ctl, int write,
> > if (new_value > max || new_value < min)
> > return -EINVAL;
> >
> > - net->sctp.rto_max = new_value;
> > + WRITE_ONCE(net->sctp.rto_max, new_value);
> > }
> >
> > return ret;
>
> [Severity: High]
> Do the handlers this patch edits still contain plain loads of these same
> fields?
>
> proc_sctp_do_rto_min() reads rto_max through extra2 to bound the new
> value. proc_sctp_do_rto_max() reads rto_min through extra1 in the same
> way:
>
> net/sctp/sysctl.c:proc_sctp_do_rto_min() {
> ...
> unsigned int min = *(unsigned int *) ctl->extra1;
> unsigned int max = *(unsigned int *) ctl->extra2;
> ...
> }
>
> sctp_sysctl_net_register() points these at the live per-netns fields. The
> static sctp_net_table does the same for init_net:
>
> table[SCTP_RTO_MIN_IDX].extra2 = &net->sctp.rto_max;
> table[SCTP_RTO_MAX_IDX].extra1 = &net->sctp.rto_min;
>
> So when writes to /proc/sys/net/sctp/rto_min and rto_max run at the same
> time, proc_sctp_do_rto_min() does a plain read of rto_max while
> proc_sctp_do_rto_max() does WRITE_ONCE(net->sctp.rto_max, ...). The same
> thing happens in the other direction for rto_min. Nothing serializes
> these two handlers against each other.
>
> The read branch of proc_sctp_do_hmac_alg() also still loads
> cookie_auth_enable without READ_ONCE():
>
> if (net->sctp.cookie_auth_enable)
> tbl.data = (char *)"sha256";
> else
> tbl.data = (char *)"none";
>
> This can race with the WRITE_ONCE() stores above when cookie_hmac_alg is
> read and written at the same time.
>
> The commit message lists rto_min, rto_max and the cookie_hmac_alg handler
> among the races being closed. The readers of these fields in
> sctp_init_sock() now use READ_ONCE().
>
> Should these three loads in the handlers use READ_ONCE() too? Otherwise
> KCSAN can still report a marked write racing with a plain read on these
> fields.
This one also looks like it should be addressed.
--
pw-bot: changes-requested
next prev parent reply other threads:[~2026-11-13 17:15 UTC|newest]
Thread overview: 52+ 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 3:01 ` sashiko-bot
2026-11-10 5:53 ` netdev-bot+sashiko
2026-11-13 17:09 ` Simon Horman
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-10 3:01 ` sashiko-bot
2026-11-13 17:10 ` Simon Horman
2026-11-09 2:52 ` [PATCH net-next 03/14] ipv6: annotate data-races around addrconf sysctls Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-13 17:13 ` Simon Horman
2026-11-09 2:52 ` [PATCH net-next 04/14] ipv6: annotate data-races around icmpv6 reply sysctls Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-13 17:13 ` Simon Horman
2026-11-09 2:52 ` [PATCH net-next 05/14] calipso: annotate data-races around cache sysctls Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-10 5:53 ` netdev-bot+sashiko
2026-11-13 17:14 ` Simon Horman
2026-11-09 2:52 ` [PATCH net-next 06/14] sctp: annotate data-races around sctp sysctls Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-10 5:53 ` netdev-bot+sashiko
2026-11-13 17:14 ` Simon Horman [this message]
2026-11-09 2:52 ` [PATCH net-next 07/14] mptcp: annotate data-races around pernet sysctls Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-10 11:28 ` Matthieu Baerts
2026-11-09 2:52 ` [PATCH net-next 08/14] rds: annotate data-races around core rds sysctls Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-13 17:15 ` Simon Horman
2026-11-09 2:52 ` [PATCH net-next 09/14] netfilter: conntrack: annotate data-races around conntrack sysctls Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-13 17:16 ` Simon Horman
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 3:01 ` sashiko-bot
2026-11-10 5:53 ` netdev-bot+sashiko
2026-11-13 17:16 ` Simon Horman
2026-11-09 2:52 ` [PATCH net-next 11/14] ipvs: annotate data-races around lblc_expiration and lblcr_expiration Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-13 17:17 ` Simon Horman
2026-11-09 2:52 ` [PATCH net-next 12/14] net/smc: annotate data-races around smc sysctls Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-12 4:54 ` Dust Li
2026-11-09 2:52 ` [PATCH net-next 13/14] netfilter: conntrack: annotate data-races around timeout and tcp sysctls Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-13 17:19 ` Simon Horman
2026-11-09 2:52 ` [PATCH net-next 14/14] netfilter: cttimeout: annotate data-races around the default timeouts Jiayuan Chen
2026-11-10 3:01 ` sashiko-bot
2026-11-10 5:53 ` netdev-bot+sashiko
2026-11-13 17:20 ` Simon Horman
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
2026-11-09 4:59 ` MPTCP CI
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=20261113171452.GQ18859@horms.kernel.org \
--to=horms@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=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-bot+sashiko@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.