All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cen Zhang (Microsoft Security FORGE Labs)" <cenzhang@linux.microsoft.com>
To: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@kernel.org>
Cc: Amery Hung <ameryhung@gmail.com>,
	Xuanqiang Luo <xuanqiang.luo@linux.dev>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	Fushuai Wang <wangfushuai@baidu.com>,
	Weiming Shi <bestswngs@gmail.com>,
	Matt Bobrowski <mattbobrowski@google.com>,
	Kees Cook <kees@kernel.org>,
	Menglong Dong <menglong8.dong@gmail.com>,
	bpf@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	AutonomousCodeSecurity@microsoft.com, xmei5@asu.edu,
	tgopinath@linux.microsoft.com, kys@microsoft.com
Subject: [PATCH bpf v2] bpf: Fix NULL pointer dereference in __bpf_sk_storage_map_seq_show
Date: Fri, 11 Sep 2026 10:03:08 -0400	[thread overview]
Message-ID: <20260911140308.81560-1-cenzhang@linux.microsoft.com> (raw)

Iterating a sk_storage map is a two-stage operation:
bpf_sk_storage_map_seq_find_next() returns a selem, then
__bpf_sk_storage_map_seq_show() uses it. The latter re-reads
selem->local_storage via rcu_dereference() without checking for NULL.
A concurrent socket close can unlink the selem and clear that pointer
between the two stages, causing a NULL dereference of sk_storage->owner.

Oops: general protection fault, probably for non-canonical
   address 0xdffffc0000000011
  net/core/bpf_sk_storage.c:809 __bpf_sk_storage_map_seq_show()
  bpf_seq_read+0x366/0x1120
  vfs_read+0x174/0xa50
  ksys_read+0xfc/0x1d0

Return SEQ_SKIP if the re-read yields NULL. This prevents the dereference
and tells bpf_seq_read() that the stale element was skipped, so it does
not consume an iterator sequence number without running the BPF program.

Fixes: 0be08389c7f2 ("bpf: Switch to bpf_selem_unlink_nofail in bpf_local_storage_{map_free, destroy}")
Reported-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Closes: https://lore.kernel.org/all/20260827051859.45511-1-blbllhy@gmail.com/
Suggested-by: Amery Hung <ameryhung@gmail.com>
Suggested-by: Xuanqiang Luo <xuanqiang.luo@linux.dev>
Link: https://lore.kernel.org/all/CAMB2axNFOC9G2RwOCnsWDth83REMWnmPE8gxMwbLYoGusw9miA@mail.gmail.com/
Link: https://lore.kernel.org/all/c3f2a61d-d5bc-454c-987d-717b5f8c8809@linux.dev/
Cc: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) <cenzhang@linux.microsoft.com>
Assisted-by: Copilot (Grok 4.6)
---
Changes in v2:
- Return SEQ_SKIP instead of 0 when the storage disappeared, preserving
  the iterator sequence number for the next valid element.
- Correct the Fixes tag to the commit that switched the destruction path
  to bpf_selem_unlink_nofail().
- Rebase onto the current bpf master branch.

 net/core/bpf_sk_storage.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
index 1d295a8769fa..7d02245aa704 100644
--- a/net/core/bpf_sk_storage.c
+++ b/net/core/bpf_sk_storage.c
@@ -806,6 +806,8 @@ static int __bpf_sk_storage_map_seq_show(struct seq_file *seq,
 		ctx.map = info->map;
 		if (selem) {
 			sk_storage = rcu_dereference(selem->local_storage);
+			if (!sk_storage)
+				return SEQ_SKIP;
 			ctx.sk = sk_storage->owner;
 			ctx.value = SDATA(selem)->data;
 		}

base-commit: 15071f2a1263e82150c77eeb1e94dbfc31950a8e
-- 
2.55.0

             reply	other threads:[~2026-09-11 14:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 14:03 Cen Zhang (Microsoft Security FORGE Labs) [this message]
2026-09-11 14:24 ` [PATCH bpf v2] bpf: Fix NULL pointer dereference in __bpf_sk_storage_map_seq_show luoxuanqiang
2026-09-11 14:28 ` sashiko-bot
2026-09-11 15:34   ` Cen Zhang (Microsoft Security FORGE Labs)

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=20260911140308.81560-1-cenzhang@linux.microsoft.com \
    --to=cenzhang@linux.microsoft.com \
    --cc=AutonomousCodeSecurity@microsoft.com \
    --cc=ameryhung@gmail.com \
    --cc=ast@kernel.org \
    --cc=bestswngs@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kees@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kys@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=mattbobrowski@google.com \
    --cc=menglong8.dong@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=tgopinath@linux.microsoft.com \
    --cc=wangfushuai@baidu.com \
    --cc=xmei5@asu.edu \
    --cc=xuanqiang.luo@linux.dev \
    /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.