All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dudu Lu <phx0fer@gmail.com>
To: john.fastabend@gmail.com, jakub@cloudflare.com, jiayuan.chen@linux.dev
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org
Subject: [PATCH bpf] bpf, sockmap: use READ_ONCE/WRITE_ONCE for saved_data_ready in the verdict path
Date: Wed, 21 Oct 2026 23:56:29 +0800	[thread overview]
Message-ID: <20261021155629.68813-1-phx0fer@gmail.com> (raw)

sk_psock_start_verdict() and sk_psock_stop_verdict() access
psock->saved_data_ready with plain loads and stores, while the sibling
sk_psock_stop_strp() uses WRITE_ONCE for the same field.  sock_map_link()
/ sock_map_unref() touch the same psock from another CPU without the
lock, so KCSAN reports the race:

  BUG: KCSAN: data-race in sock_map_link / sock_map_unref
  BUG: KCSAN: data-race in sk_psock_start_verdict / sock_map_unref

Use READ_ONCE() for the reads and WRITE_ONCE() for the writes, matching
the strp sibling.

Fixes: 2ef2b20cf4e0 ("net: annotate data-races around sk->sk_{data_ready,write_space}")
Assisted-by: LLM
Signed-off-by: Dudu Lu <phx0fer@gmail.com>
---
Tested base
-----------
Detected on Linux 7.3-rc4 (commit 93f51579e7df), arm64 QEMU guest.
Re-checked against mainline f47d223627f8 (v7.3-341): the affected code
is unchanged between the two, so the bug is still present there.
Checked against linux-next next-20261021 (commit 9a482184d910): the
affected code is unchanged there as well, so the bug is still present in
linux-next too.

Reproducer status
-----------------
A reproducer was written and executed on an arm64 QEMU guest (KCSAN); it
reported the race.  The reproducer source is not posted here per
Documentation/process/security-bugs.rst; it is available on request.

Triggering conditions
---------------------
CAP_BPF / the ability to update sockmap and attach verdict programs.

Notes
-----
Built and checkpatch-clean: this patch was applied on top of 7.3-rc4
(commit 93f51579e7df) and a full arm64 kernel (defconfig) was built with
it -- no new warnings or errors.  scripts/checkpatch.pl reports 0 errors,
0 warnings.

 net/core/skmsg.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/core/skmsg.c b/net/core/skmsg.c
index df385a5a961e..0bfb8c4e7f36 100644
--- a/net/core/skmsg.c
+++ b/net/core/skmsg.c
@@ -1260,10 +1260,10 @@ static void sk_psock_verdict_data_ready(struct sock *sk)
 
 void sk_psock_start_verdict(struct sock *sk, struct sk_psock *psock)
 {
-	if (psock->saved_data_ready)
+	if (READ_ONCE(psock->saved_data_ready))
 		return;
 
-	psock->saved_data_ready = sk->sk_data_ready;
+	WRITE_ONCE(psock->saved_data_ready, sk->sk_data_ready);
 	WRITE_ONCE(sk->sk_data_ready, sk_psock_verdict_data_ready);
 	WRITE_ONCE(sk->sk_write_space, sk_psock_write_space);
 }
@@ -1273,9 +1273,9 @@ void sk_psock_stop_verdict(struct sock *sk, struct sk_psock *psock)
 	psock_set_prog(&psock->progs.stream_verdict, NULL);
 	psock_set_prog(&psock->progs.skb_verdict, NULL);
 
-	if (!psock->saved_data_ready)
+	if (!READ_ONCE(psock->saved_data_ready))
 		return;
 
 	WRITE_ONCE(sk->sk_data_ready, psock->saved_data_ready);
-	psock->saved_data_ready = NULL;
+	WRITE_ONCE(psock->saved_data_ready, NULL);
 }

             reply	other threads:[~2026-10-21 15:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 15:56 Dudu Lu [this message]
2026-10-21 16:10 ` [PATCH bpf] bpf, sockmap: use READ_ONCE/WRITE_ONCE for saved_data_ready in the verdict path sashiko-bot
2026-10-21 16:37 ` bot+bpf-ci
2026-10-21 16:45 ` Alexei Starovoitov
2026-10-21 20:30 ` Jakub Sitnicki
2026-10-22  3:37 ` Jiayuan Chen
2026-10-22  5:48 ` [PATCH bpf v2] bpf, sockmap: annotate the psock teardown data races Dudu Lu
2026-10-22 15:40   ` Alexei Starovoitov
2026-10-23 18:49     ` Jakub Sitnicki
2026-10-23 18:53       ` Alexei Starovoitov
2026-10-26 12:33         ` Jakub Sitnicki
2026-10-27  5:10           ` phx
2026-10-27 16:33             ` Jakub Sitnicki
2026-10-27 16:46               ` Alexei Starovoitov
2026-10-27 17:34                 ` Jakub Sitnicki

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=20261021155629.68813-1-phx0fer@gmail.com \
    --to=phx0fer@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=jakub@cloudflare.com \
    --cc=jiayuan.chen@linux.dev \
    --cc=john.fastabend@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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.