[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

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

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

[Michal Luczaj]

On 10/17/26 01:52, Alexei Starovoitov wrote:
> 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...

So we don't care about having a stable socket state while iterating? Which
is the case for iter/sockmap, but is unlike iter/{tcp,udp}.

>> +		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.

I'm not sure I see the (stream sock) issue above. psock->sk_pair holds the
peer, so peer pointer remains valid during proto update. iter/sockmap is
safe, because sk is held by RCU. And for iter/unix we currently take
unix_state_lock().

But iter/sockmap dgram peer is a problem, right? No sk_pair, no lock, and
connect(AF_UNSPEC) can get the peer dropped.

> Should we restrict it to ctx->sk somehow?

I recall a discussion about having BPF helpers accept only trusted
pointers:
https://lore.kernel.org/bpf/CAADnVQK_93g_KkNFYXSr8ZvA1fYh4hoFRJCJFPS-zs4ox0HhAA@mail.gmail.com/
Restricting only iter/unix seems better?

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

[Alexei Starovoitov]

On Mon, Oct 19, 2026 at 08:20 AM Michal Luczaj <mhal@rbox.co> wrote:
> On 10/17/26 01:52, Alexei Starovoitov wrote:
>> 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...
>
> So we don't care about having a stable socket state while iterating? Which
> is the case for iter/sockmap, but is unlike iter/{tcp,udp}.

Not sure. Is there a value?

> I'm not sure I see the (stream sock) issue above. psock->sk_pair holds the
> peer, so peer pointer remains valid during proto update. iter/sockmap is
> safe, because sk is held by RCU. And for iter/unix we currently take
> unix_state_lock().

got it. you're right.

>> Should we restrict it to ctx->sk somehow?
>
> I recall a discussion about having BPF helpers accept only trusted
> pointers:
> https://lore.kernel.org/bpf/CAADnVQK_93g_KkNFYXSr8ZvA1fYh4hoFRJCJFPS-zs4ox0HhAA@mail.gmail.com/
> Restricting only iter/unix seems better?

we just discussed at bpf sync meeting that it's time to
finally remove plain PTR_TO_BTF_ID.
Otherwise we keep hitting this bug everywhere.

in the meantime can we do it for this one arg ?
Mark ctx->sk as PTR_TRUSTED in sock_map_iter_reg
like iter/tcp and iter/udp do ?

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

[Jakub Sitnicki]

On Fri, Oct 16, 2026 at 11:09 PM +02, Michal Luczaj wrote:
> @@ -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:

Explicit bailout when prog->type == BPF_PROG_TYPE_EXT might be more
self-explanatory.

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

[Michal Luczaj]

On 10/19/26 13:16, Jakub Sitnicki wrote:
> On Fri, Oct 16, 2026 at 11:09 PM +02, Michal Luczaj wrote:
>> @@ -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:
> 
> Explicit bailout when prog->type == BPF_PROG_TYPE_EXT might be more
> self-explanatory.

I just though that such explicit allow-criteria approach is safer than a
deny-criteria (should other special prog types come along). But I agree
that would be more self-explanatory.

[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