[PATCH RFC v2 0/4] bpf, sockmap: Restrict iter-context sockmap updates to sockmap iterators

[PATCH RFC v2 0/4] bpf, sockmap: Restrict iter-context sockmap updates to sockmap iterators

[Michal Luczaj]

Follow-up to Sashiko's report [1] and the decision to restrict which
iterator may perform sockmap updates [2].

Short series: remove about-to-be-stale test, restrict updates, add a
negative test. Related bonus: mark bpf_iter__sockmap::sk as PTR_TRUSTED.

[1]: https://msgid.link/20260626205814.BAC3C1F000E9@smtp.kernel.org
[2]: https://msgid.link/87echn2fhd.fsf@cloudflare.com

Signed-off-by: Michal Luczaj <mhal@rbox.co>
---
Changes in v2:
- Commit 7cc639dc45c5 ("bpf: Don't take an extension for an iterator
  program") and commit b83bacf2161d ("bpf: Don't take a program with a
  target program for an iterator") landed. Drop the redundant
  env->prog->type check.
- Mark bpf_iter__sockmap::sk as PTR_TRUSTED (Alexei)
- Link to v1: https://patch.msgid.link/20261016-sockmap-update-limit-iter-v1-0-23fa946db59e@rbox.co

To: Andrii Nakryiko <andrii@kernel.org>
To: Eduard Zingerman <eddyz87@gmail.com>
To: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Alexei Starovoitov <ast@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: Martin KaFai Lau <martin.lau@linux.dev>
To: Song Liu <song@kernel.org>
To: Yonghong Song <yonghong.song@linux.dev>
To: Jiri Olsa <jolsa@kernel.org>
To: Emil Tsalapatis <emil@etsalapatis.com>
To: Shuah Khan <shuah@kernel.org>
To: John Fastabend <john.fastabend@gmail.com>
To: Eric Dumazet <edumazet@kernel.org>
To: Kuniyuki Iwashima <kuniyu@google.com>
To: Paolo Abeni <pabeni@redhat.com>
To: Willem de Bruijn <willemb@google.com>
To: Jakub Sitnicki <jakub@cloudflare.com>
To: Jiayuan Chen <jiayuan.chen@linux.dev>
To: "David S. Miller" <davem@davemloft.net>
To: Jakub Kicinski <kuba@kernel.org>
To: Simon Horman <horms@kernel.org>
Cc: bpf@vger.kernel.org
Cc: linux-kselftest@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org

---
Michal Luczaj (4):
      selftests/bpf: Remove sockmap update from bpf_iter_unix
      bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap
      selftests/bpf: Add negative test for sockmap update from non-sockmap iter
      bpf: Mark bpf_iter__sockmap::sk as PTR_TRUSTED

 kernel/bpf/verifier.c                                      |  4 +++-
 net/core/sock_map.c                                        |  2 +-
 tools/testing/selftests/bpf/progs/bpf_iter_unix.c          | 10 ----------
 .../testing/selftests/bpf/progs/verifier_sockmap_mutate.c  | 14 ++++++++++++++
 4 files changed, 18 insertions(+), 12 deletions(-)
---
base-commit: a30c772627b2ef4bc715332b1b04938a914556cd
change-id: 20261008-sockmap-update-limit-iter-d03ea25f9775

Best regards,
--  
Michal Luczaj <mhal@rbox.co>

[PATCH RFC v2 1/4] selftests/bpf: Remove sockmap update from bpf_iter_unix

[Michal Luczaj]

BPF iterator programs that can update sockmaps will be limited to
iter/sockmap. Remove the update from the unix selftest.

This reverts commit 997b8483d44c ("selftests/bpf: Extend bpf_iter_unix to
attempt deadlocking").

Signed-off-by: Michal Luczaj <mhal@rbox.co>
---
 tools/testing/selftests/bpf/progs/bpf_iter_unix.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/tools/testing/selftests/bpf/progs/bpf_iter_unix.c b/tools/testing/selftests/bpf/progs/bpf_iter_unix.c
index 3061b148f338..90beada0386d 100644
--- a/tools/testing/selftests/bpf/progs/bpf_iter_unix.c
+++ b/tools/testing/selftests/bpf/progs/bpf_iter_unix.c
@@ -7,13 +7,6 @@
 
 char _license[] SEC("license") = "GPL";
 
-SEC(".maps") struct {
-	__uint(type, BPF_MAP_TYPE_SOCKMAP);
-	__uint(max_entries, 1);
-	__type(key, __u32);
-	__type(value, __u64);
-} sockmap;
-
 static long sock_i_ino(const struct sock *sk)
 {
 	const struct socket *sk_socket = sk->sk_socket;
@@ -82,8 +75,5 @@ int dump_unix(struct bpf_iter__unix *ctx)
 
 	BPF_SEQ_PRINTF(seq, "\n");
 
-	/* Test for deadlock. */
-	bpf_map_update_elem(&sockmap, &(int){0}, sk, 0);
-
 	return 0;
 }

-- 
2.56.0

[PATCH RFC v2 2/4] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap

[Michal Luczaj]

Among tracing progs, allow only iter/sockmap to update sockmaps and
sockhashes. Previously, any BPF_TRACE_ITER program could perform these
updates, which caused locking issues in specific scenarios [1][2][3]. This
tightening is part of the broader effort to lock down the BPF API [4].

[1]: commit 4d328dd69538 ("bpf, sockmap: Fix af_unix iter deadlock")
[2]: commit 64c2f93fc325 ("bpf, sockmap: Take state lock for af_unix iter")
[3]: https://msgid.link/87echn2fhd.fsf@cloudflare.com
[4]: https://msgid.link/akRZ_e7DJh2aP-2i@john-p8

Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://msgid.link/20260626205814.BAC3C1F000E9@smtp.kernel.org
Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: Michal Luczaj <mhal@rbox.co>
---
 kernel/bpf/verifier.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 1b6c0674ff6a..4dadfe9505a2 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -10487,6 +10487,7 @@ static bool may_update_sockmap(struct bpf_verifier_env *env, int func_id)
 {
 	enum bpf_attach_type eatype = env->prog->expected_attach_type;
 	enum bpf_prog_type type = resolve_prog_type(env->prog);
+	const char *afname = env->prog->aux->attach_func_name;
 
 	if (func_id != BPF_FUNC_map_update_elem &&
 	    func_id != BPF_FUNC_map_delete_elem)
@@ -10497,7 +10498,8 @@ static bool may_update_sockmap(struct bpf_verifier_env *env, int func_id)
 	 */
 	switch (type) {
 	case BPF_PROG_TYPE_TRACING:
-		if (eatype == BPF_TRACE_ITER)
+		if (eatype == BPF_TRACE_ITER &&
+		    !strcmp(afname + strlen(BPF_ITER_FUNC_PREFIX), "sockmap"))
 			return true;
 		break;
 	case BPF_PROG_TYPE_SOCK_OPS:

-- 
2.56.0

[PATCH RFC v2 3/4] selftests/bpf: Add negative test for sockmap update from non-sockmap iter

[Michal Luczaj]

Iterator-context sockmap updates are now restricted to iter/sockmap. Add a
test that attempts an update from iter/unix and expects it to fail.

Signed-off-by: Michal Luczaj <mhal@rbox.co>
---
 .../testing/selftests/bpf/progs/verifier_sockmap_mutate.c  | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/tools/testing/selftests/bpf/progs/verifier_sockmap_mutate.c b/tools/testing/selftests/bpf/progs/verifier_sockmap_mutate.c
index 20332a731d4e..1516fe1524bb 100644
--- a/tools/testing/selftests/bpf/progs/verifier_sockmap_mutate.c
+++ b/tools/testing/selftests/bpf/progs/verifier_sockmap_mutate.c
@@ -19,6 +19,12 @@ struct bpf_iter__sockmap {
 	};
 } __attribute__((preserve_access_index));
 
+struct bpf_iter__unix {
+	union {
+		struct sock *unix_sk;
+	};
+} __attribute__((preserve_access_index));
+
 struct {
 	__uint(type, BPF_MAP_TYPE_SOCKHASH);
 	__uint(max_entries, 1);
@@ -113,6 +119,14 @@ int test_trace_iter(struct bpf_iter__sockmap *ctx)
 	return 0;
 }
 
+SEC("iter/unix")
+__failure __msg("cannot update sockmap in this context")
+int test_trace_iter_unix(struct bpf_iter__unix *ctx)
+{
+	test_sockmap_mutate(ctx->unix_sk);
+	return 0;
+}
+
 SEC("raw_tp/kfree")
 __failure __msg("cannot update sockmap in this context")
 int test_raw_tp_delete(const void *ctx __always_unused)

-- 
2.56.0

[PATCH RFC v2 4/4] bpf: Mark bpf_iter__sockmap::sk as PTR_TRUSTED

[Michal Luczaj]

In preparation for plain-PTR_TO_BTF_ID removal: allow calling bpf helpers
with sk provided by iter/sockmap.

Suggested-by: Alexei Starovoitov <ast@kernel.org>
Link: https://msgid.link/DM92JCFA4X4U.30MTDH0KCPTJ@gmail.com
Signed-off-by: Michal Luczaj <mhal@rbox.co>
---
 net/core/sock_map.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 057e2f3c0265..2a2a07372818 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -1989,7 +1989,7 @@ static struct bpf_iter_reg sock_map_iter_reg = {
 		{ offsetof(struct bpf_iter__sockmap, key),
 		  PTR_TO_BUF | PTR_MAYBE_NULL | MEM_RDONLY },
 		{ offsetof(struct bpf_iter__sockmap, sk),
-		  PTR_TO_BTF_ID_OR_NULL },
+		  PTR_TO_BTF_ID_OR_NULL | PTR_TRUSTED },
 	},
 };
 

-- 
2.56.0

Re: [PATCH RFC v2 4/4] bpf: Mark bpf_iter__sockmap::sk as PTR_TRUSTED

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] bpf: unlocked socket destroy via bpf_sock_destroy() in iter/sockmap
--

commit 97a776f78529c30ceec62254569454f51205e10f
Author: Michal Luczaj <mhal@rbox.co>

bpf: Mark bpf_iter__sockmap::sk as PTR_TRUSTED

This commit marks the sk field in struct bpf_iter__sockmap as PTR_TRUSTED so
BPF helpers and kfuncs can accept the socket pointer provided by iter/sockmap
programs.

Link: https://msgid.link/DM92JCFA4X4U.30MTDH0KCPTJ@gmail.com

> diff --git a/net/core/sock_map.c b/net/core/sock_map.c
> index 057e2f3c0265e..2a2a073728189 100644
> --- a/net/core/sock_map.c
> +++ b/net/core/sock_map.c
> @@ -1989,7 +1989,7 @@ static struct bpf_iter_reg sock_map_iter_reg = {
>  		{ offsetof(struct bpf_iter__sockmap, key),
>  		  PTR_TO_BUF | PTR_MAYBE_NULL | MEM_RDONLY },
>  		{ offsetof(struct bpf_iter__sockmap, sk),
> -		  PTR_TO_BTF_ID_OR_NULL },
> +		  PTR_TO_BTF_ID_OR_NULL | PTR_TRUSTED },

[Severity: Critical]
Does marking bpf_iter__sockmap::sk with PTR_TRUSTED allow iter/sockmap
programs to call bpf_sock_destroy() on an unlocked socket?

In net/core/filter.c, tracing_iter_filter() permits bpf_sock_destroy() for
any BPF_TRACE_ITER program as long as the caller supplies a trusted
struct sock_common pointer:

net/core/filter.c:tracing_iter_filter() {
	if (btf_id_set8_contains(&bpf_sk_iter_kfunc_ids, kfunc_id) &&
	    prog->expected_attach_type != BPF_TRACE_ITER)
		return -EACCES;
	return 0;
}

With ctx->sk marked as PTR_TRUSTED in sock_map_iter_reg, a NULL check on
ctx->sk yields a trusted struct sock pointer, which matches struct sock_common
at offset zero and is accepted by the verifier for bpf_sock_destroy().

However, unlike bpf_iter_tcp_seq_show() and bpf_iter_udp_seq_show() which
acquire lock_sock(sk) before running the BPF program, sock_map_seq_show() and
sock_hash_seq_show() in net/core/sock_map.c only hold rcu_read_lock():

sock_map_seq_show() / sock_hash_seq_show()
  -> bpf_iter_run_prog()
       -> bpf_sock_destroy()
            -> sk->sk_prot->diag_destroy(sk, ECONNABORTED)
                 -> tcp_abort() / udp_abort()

Because bpf_iter_run_prog() sets current->bpf_ctx, has_current_bpf_ctx()
returns true inside tcp_abort() and udp_abort(), causing both functions to
skip lock_sock(sk) under the assumption that the BPF context already holds the
socket lock:

net/ipv4/tcp.c:tcp_abort() {
	if (!has_current_bpf_ctx())
		lock_sock(sk);
	...
}

net/ipv4/udp.c:udp_abort() {
	if (!has_current_bpf_ctx())
		lock_sock(sk);
	...
}

For UDP sockets in a sockmap or sockhash, udp_abort() will run
__udp_disconnect() and sk->sk_prot->rehash(sk) with no socket lock held at
all.

For TCP_LISTEN sockets in a sockmap or sockhash, tcp_abort() will execute
tcp_set_state(sk, TCP_CLOSE) -> inet_put_port(sk) and inet_csk_listen_stop(sk)
before bh_lock_sock(sk) without holding lock_sock(sk), racing with concurrent
close() or abort paths.

For established TCP sockets, tcp_abort() will only take bh_lock_sock(sk)
without checking sock_owned_by_user(sk), running tcp_write_queue_purge(sk) and
tcp_done(sk) concurrently with process-context holders of lock_sock(sk). If
this races with __tcp_close() after sock_orphan(sk) sets SOCK_DEAD, both
tcp_done() and __tcp_close() can call inet_csk_destroy_sock(sk), leading to a
double sock_put(sk) and use-after-free.

Should sock_map_seq_show() and sock_hash_seq_show() acquire lock_sock(sk), or
should bpf_sock_destroy() be restricted from running in iter/sockmap?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-sockmap-update-limit-iter-v2-0-e96a63c43b39@rbox.co?part=4

Re: [PATCH RFC v2 2/4] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

> bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap

TL;DR: Unresolved question: tracing_iter_filter() still allows
bpf_sock_destroy() from iter/sockmap, so tcp_abort() may run on a socket whose
lock isn't held. Should it be limited to iter/tcp and iter/udp?

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 1b6c0674ff6a..4dadfe9505a2 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c

[ ... ]

> @@ -10497,7 +10498,8 @@ static bool may_update_sockmap(struct bpf_verifier_env *env, int func_id)
>  	 */
>  	switch (type) {
>  	case BPF_PROG_TYPE_TRACING:
> -		if (eatype == BPF_TRACE_ITER)
> +		if (eatype == BPF_TRACE_ITER &&
> +		    !strcmp(afname + strlen(BPF_ITER_FUNC_PREFIX), "sockmap"))
>  			return true;
>  		break;
>  	case BPF_PROG_TYPE_SOCK_OPS:

Was the request to also restrict tracing_iter_filter() to iter/tcp and
iter/udp ever resolved?

In the v1 thread Alexei Starovoitov wrote:

  Pls send the PTR_TRUSTED part in v2. I'd also limit tracing_iter_filter()
  to iter/tcp and iter/udp.

The reply to that was that once bpf_iter__sockmap::sk is PTR_TRUSTED,
iter/sockmap could call bpf_sock_destroy() on an unlocked sk.  The v2 series
adds the PTR_TRUSTED marking but does not touch tracing_iter_filter(), and I
could not find a follow-up on the v2 thread:

net/core/filter.c:tracing_iter_filter() {
	if (btf_id_set8_contains(&bpf_sk_iter_kfunc_ids, kfunc_id) &&
	    prog->expected_attach_type != BPF_TRACE_ITER)
		return -EACCES;
	...
}

This still allows bpf_sock_destroy() from any BPF_TRACE_ITER program,
including iter/sockmap.

sock_map_seq_show() holds only the RCU read lock, and tcp_abort() skips
lock_sock() when called from a BPF context.  Can an iter/sockmap program
now reach tcp_abort() through bpf_sock_destroy() on a socket whose lock is
not held?

If so, should tracing_iter_filter() be limited to iter/tcp and iter/udp as
requested, or is there a reason it can stay as it is?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/41373332573

Re: [PATCH RFC v2 0/4] bpf, sockmap: Restrict iter-context sockmap updates to sockmap iterators

[Michal Luczaj]

On 11/2/26 02:15, Michal Luczaj wrote:
> Follow-up to Sashiko's report [1] and the decision to restrict which
> iterator may perform sockmap updates [2].
> 
> Short series: remove about-to-be-stale test, restrict updates, add a
> negative test. Related bonus: mark bpf_iter__sockmap::sk as PTR_TRUSTED.
> 
> [1]: https://msgid.link/20260626205814.BAC3C1F000E9@smtp.kernel.org
> [2]: https://msgid.link/87echn2fhd.fsf@cloudflare.com

Apologies, I forgot to strip the RFC prefix (which I set thinking bpf-next
is closed).

Sashikos reviews just as pointed out by Alexei: bpf_sock_destroy(). I left
out the tracing_iter_filter() change since I was not confident I understood
the reasoning behind it.

thanks,
Michal