[PATCH bpf-next 0/3] bpf, sockmap: Restrict iter-context sockmap updates to sockmap iterators

[PATCH bpf-next 0/3] 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].

Three-patch set: remove about-to-be-stale test, restrict updates, add a
negative test.

[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>
---
Michal Luczaj (3):
      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

 kernel/bpf/verifier.c                                      |  8 +++++++-
 tools/testing/selftests/bpf/progs/bpf_iter_unix.c          | 10 ----------
 .../testing/selftests/bpf/progs/verifier_sockmap_mutate.c  | 14 ++++++++++++++
 3 files changed, 21 insertions(+), 11 deletions(-)
---
base-commit: 645f5fcf7a5582f5d6ed2322f41cb34076c63b2c
change-id: 20261008-sockmap-update-limit-iter-d03ea25f9775

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

[PATCH bpf-next 1/3] 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 bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap

[Michal Luczaj]

Among iterators, 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].

env->prog->type check covers the BPF_PROG_TYPE_EXT case. Without it, a
non-sockmap iterator, e.g. iter/unix, could call a function named
bpf_iter_sockmap() that has been freplace'd with sockmap-update logic, and
still pass the check.

[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 | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index ddfa0c6d2755..c63abb13ec6d 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -10331,6 +10331,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)
@@ -10341,7 +10342,12 @@ 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)
+		/* iter/sockmap only; type check rejects a freplace of any
+		 * iterator's bpf_iter_sockmap() subprog.
+		 */
+		if (eatype == BPF_TRACE_ITER &&
+		    env->prog->type == BPF_PROG_TYPE_TRACING &&
+		    !strcmp(afname + strlen(BPF_ITER_FUNC_PREFIX), "sockmap"))
 			return true;
 		break;
 	case BPF_PROG_TYPE_SOCK_OPS:

-- 
2.56.0

[PATCH bpf-next 3/3] 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

Re: [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] bpf: may_update_sockmap() allows attach_func_name spoofing via dst_prog
- [Low] bpf: multi-line comment style violation in may_update_sockmap()
--

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

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

This commit restricts sockmap and sockhash updates from BPF_TRACE_ITER
programs so that only iter/sockmap programs are permitted to perform them,
checking both env->prog->type and env->prog->aux->attach_func_name in
may_update_sockmap().

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index ddfa0c6d2755f..c63abb13ec6dd 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -10331,6 +10331,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)
> @@ -10341,7 +10342,12 @@ 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)
> +		/* iter/sockmap only; type check rejects a freplace of any
> +		 * iterator's bpf_iter_sockmap() subprog.
> +		 */

[Severity: Low]
This isn't a bug, but in the BPF subsystem multi-line comments should have
the opening /* on its own line with the comment text starting on the next
line. Should this comment in may_update_sockmap() follow that style?

> +		if (eatype == BPF_TRACE_ITER &&
> +		    env->prog->type == BPF_PROG_TYPE_TRACING &&
> +		    !strcmp(afname + strlen(BPF_ITER_FUNC_PREFIX), "sockmap"))
>  			return true;

[Severity: High]
Can a non-sockmap BPF_TRACE_ITER program still bypass this check in
may_update_sockmap() by specifying attach_prog_fd (dst_prog) during
BPF_PROG_LOAD?

Checking env->prog->type == BPF_PROG_TYPE_TRACING excludes BPF_PROG_TYPE_EXT,
but bpf_prog_load_check_attach() in kernel/bpf/syscall.c also allows
attach_prog_fd (setting prog->aux->dst_prog) when prog_type is
BPF_PROG_TYPE_TRACING.

In kernel/bpf/verifier.c, bpf_check_attach_target() rejects tgt_prog for
BPF_TRACE_RAW_TP, but does not reject tgt_prog != NULL for BPF_TRACE_ITER:

kernel/bpf/verifier.c:bpf_check_attach_target() {
	...
	if (tgt_prog) {
		...
		btf = tgt_prog->aux->btf;
	} else {
		btf = bpf_get_btf_vmlinux();
		...
	}
	...
	case BPF_TRACE_ITER:
		if (!btf_type_is_func(t)) {
			bpf_log(log, "attach_btf_id %u is not a function\n",
				btf_id);
			return -EINVAL;
		}
		...
}

When check_attach_btf_id() calls bpf_check_attach_target(), tgt_info.tgt_name
is resolved from tgt_prog->aux->btf (which is user-controlled BTF) and stored
in prog->aux->attach_func_name before calling bpf_iter_prog_supported(prog):

kernel/bpf/bpf_iter.c:bpf_iter_prog_supported() {
	const char *attach_fname = prog->aux->attach_func_name;
	u32 prog_btf_id = prog->aux->attach_btf_id;
	...
	list_for_each_entry(iter, &targets, list) {
		if (iter->btf_id && iter->btf_id == prog_btf_id) {
			tinfo = iter;
			break;
		}
		if (!strcmp(attach_fname + prefix_len, iter->reg_info->target)) {
			cache_btf_id(iter, prog);
			tinfo = iter;
			break;
		}
	}
	...
}

If a user loads a target BPF program whose BTF defines a function named
bpf_iter_sockmap at the same BTF ID as another iterator in vmlinux BTF:

1. For an iterator appearing before sockmap in the targets list (such as
   bpf_sk_storage_map, which is registered via late_initcall in
   net/core/bpf_sk_storage.c after net/core/sock_map.c), once its
   iter->btf_id is cached, bpf_iter_prog_supported() matches
   iter->btf_id == prog_btf_id first and sets up ctx_arg_info for
   bpf_sk_storage_map. Then may_update_sockmap() sees afname as
   bpf_iter_sockmap and allows sockmap updates, and bpf_iter_link_attach()
   attaches the program to bpf_sk_storage_map. Because
   __bpf_sk_storage_map_seq_show() only holds rcu_read_lock() on
   sk_storage->owner without locking the socket, updating a sockmap with an
   AF_UNIX stream socket from this iterator can trigger the
   unix_stream_bpf_update_proto() sk_pair race described in commit
   64c2f93fc325 ("bpf, sockmap: Take state lock for af_unix iter").

2. For an iterator appearing after sockmap in targets (such as iter/unix),
   bpf_iter_prog_supported() matches "sockmap" by name at the sockmap entry
   and calls cache_btf_id(iter, prog), overwriting sockmap's cached
   iter->btf_id with the other iterator's BTF ID and breaking subsequent
   legitimate iter/sockmap attachments in bpf_iter_link_attach(). In
   addition, bpf_iter_link_replace() only compares type,
   expected_attach_type, and attach_btf_id, allowing this program to replace
   an existing iter/unix link.

Should bpf_check_attach_target() reject tgt_prog != NULL for BPF_TRACE_ITER
(or should may_update_sockmap() check !env->prog->aux->dst_prog)?

>  		break;
>  	case BPF_PROG_TYPE_SOCK_OPS:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-sockmap-update-limit-iter-v1-1-23fa946db59e@rbox.co?part=2

Re: [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap

[Alexei Starovoitov]

On Fri, Oct 16, 2026 at 11:09 PM Michal Luczaj <mhal@rbox.co> wrote:
> [2]: commit 64c2f93fc325 ("bpf, sockmap: Take state lock for af_unix iter")

unix_state_lock() in bpf_iter_unix_seq_show() was added only for
unix_stream_bpf_update_proto() called from the iter prog.
iter/unix cannot get there anymore.
can we drop it ? can be a follow up...

> +		if (eatype == BPF_TRACE_ITER &&
> +		    env->prog->type == BPF_PROG_TYPE_TRACING &&
> +		    !strcmp(afname + strlen(BPF_ITER_FUNC_PREFIX), "sockmap"))
>  			return true;

iter/sockmap prog is not limited to ctx->sk it seems.
bpf_skc_to_unix_sock(ctx->sk)->peer is a plain PTR_TO_BTF_ID and
the value arg of bpf_map_update_elem() accepts it.
The peer doesn't have to be in any map, so it has no psock,
and sock_map_seq_show() holds nothing but rcu.
sock_map_update_elem() takes bh_lock_sock(), then sock_map_link() does
sk_psock_init() and unix_stream_bpf_update_proto() on a socket
that unix_release_sock() can be tearing down.
That's the same unlocked socket as in iter/task_file.

Should we restrict it to ctx->sk somehow?

pw-bot: cr