* [PATCH bpf-next 1/3] selftests/bpf: Remove sockmap update from bpf_iter_unix
2026-10-16 21:09 [PATCH bpf-next 0/3] bpf, sockmap: Restrict iter-context sockmap updates to sockmap iterators Michal Luczaj
@ 2026-10-16 21:09 ` Michal Luczaj
2026-10-16 21:09 ` [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap Michal Luczaj
2026-10-16 21:09 ` [PATCH bpf-next 3/3] selftests/bpf: Add negative test for sockmap update from non-sockmap iter Michal Luczaj
2 siblings, 0 replies; 6+ messages in thread
From: Michal Luczaj @ 2026-10-16 21:09 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Martin KaFai Lau,
Song Liu, Yonghong Song, Jiri Olsa, Emil Tsalapatis,
Ihor Solodrai, Shuah Khan, John Fastabend, Lorenz Bauer
Cc: bpf, linux-kselftest, linux-kernel, 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
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap
2026-10-16 21:09 [PATCH bpf-next 0/3] bpf, sockmap: Restrict iter-context sockmap updates to sockmap iterators Michal Luczaj
2026-10-16 21:09 ` [PATCH bpf-next 1/3] selftests/bpf: Remove sockmap update from bpf_iter_unix Michal Luczaj
@ 2026-10-16 21:09 ` Michal Luczaj
2026-10-16 22:22 ` sashiko-bot
2026-10-16 23:52 ` Alexei Starovoitov
2026-10-16 21:09 ` [PATCH bpf-next 3/3] selftests/bpf: Add negative test for sockmap update from non-sockmap iter Michal Luczaj
2 siblings, 2 replies; 6+ messages in thread
From: Michal Luczaj @ 2026-10-16 21:09 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Martin KaFai Lau,
Song Liu, Yonghong Song, Jiri Olsa, Emil Tsalapatis,
Ihor Solodrai, Shuah Khan, John Fastabend, Lorenz Bauer
Cc: bpf, linux-kselftest, linux-kernel, Michal Luczaj, Sashiko,
Jakub Sitnicki
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
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap
2026-10-16 21:09 ` [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap Michal Luczaj
@ 2026-10-16 22:22 ` sashiko-bot
2026-10-16 23:52 ` Alexei Starovoitov
1 sibling, 0 replies; 6+ messages in thread
From: sashiko-bot @ 2026-10-16 22:22 UTC (permalink / raw)
To: Michal Luczaj; +Cc: bpf
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap
2026-10-16 21:09 ` [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap Michal Luczaj
2026-10-16 22:22 ` sashiko-bot
@ 2026-10-16 23:52 ` Alexei Starovoitov
1 sibling, 0 replies; 6+ messages in thread
From: Alexei Starovoitov @ 2026-10-16 23:52 UTC (permalink / raw)
To: Michal Luczaj, Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Martin KaFai Lau, Song Liu,
Yonghong Song, Jiri Olsa, Emil Tsalapatis, Ihor Solodrai,
Shuah Khan, John Fastabend, Lorenz Bauer
Cc: bpf, linux-kselftest, linux-kernel, Sashiko, Jakub Sitnicki
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH bpf-next 3/3] selftests/bpf: Add negative test for sockmap update from non-sockmap iter
2026-10-16 21:09 [PATCH bpf-next 0/3] bpf, sockmap: Restrict iter-context sockmap updates to sockmap iterators Michal Luczaj
2026-10-16 21:09 ` [PATCH bpf-next 1/3] selftests/bpf: Remove sockmap update from bpf_iter_unix Michal Luczaj
2026-10-16 21:09 ` [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap Michal Luczaj
@ 2026-10-16 21:09 ` Michal Luczaj
2 siblings, 0 replies; 6+ messages in thread
From: Michal Luczaj @ 2026-10-16 21:09 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Martin KaFai Lau,
Song Liu, Yonghong Song, Jiri Olsa, Emil Tsalapatis,
Ihor Solodrai, Shuah Khan, John Fastabend, Lorenz Bauer
Cc: bpf, linux-kselftest, linux-kernel, 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
^ permalink raw reply related [flat|nested] 6+ messages in thread