[PATCH bpf-next 0/4] More gen_loader fixes #2

[PATCH bpf-next 0/4] More gen_loader fixes #2

[Daniel Borkmann]

Another small follow-up from the sashiko findings about signed loaders.
In particular, closing the gap to reject exclusive maps in iterators.

Daniel Borkmann (4):
  bpf: Reject exclusive maps for bpf_map_elem iterators
  libbpf: Guard add_data() against size overflow
  selftests/bpf: Keep verifier_map_ptr exercising ops pointer access
  selftests/bpf: Test that exclusive maps are rejected as iter targets

 kernel/bpf/map_iter.c                         |  4 ++
 tools/lib/bpf/gen_loader.c                    |  8 +++-
 .../selftests/bpf/prog_tests/map_excl.c       | 39 +++++++++++++++++++
 .../selftests/bpf/progs/verifier_map_ptr.c    | 34 ++++++++++++++--
 4 files changed, 80 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH bpf-next 1/4] bpf: Reject exclusive maps for bpf_map_elem iterators

[Daniel Borkmann]

Exclusive maps (aka excl_prog_hash) are meant to be reachable only
from the single program whose hash matches. This is enforced by
check_map_prog_compatibility() when the map is referenced from a
program such as signed BPF loaders.

A bpf_map_elem iterator, however, binds its target map at attach
time in bpf_iter_attach_map() instead of referencing it from the
program, so the exclusivity check is never reached. On top of that,
the iterator exposes the map value as a writable buffer.

Fixes: baefdbdf6812 ("bpf: Implement exclusive map creation")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
 kernel/bpf/map_iter.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/bpf/map_iter.c b/kernel/bpf/map_iter.c
index 261a03ea73d3..ae0741a09c6d 100644
--- a/kernel/bpf/map_iter.c
+++ b/kernel/bpf/map_iter.c
@@ -112,6 +112,10 @@ static int bpf_iter_attach_map(struct bpf_prog *prog,
 	map = bpf_map_get_with_uref(linfo->map.map_fd);
 	if (IS_ERR(map))
 		return PTR_ERR(map);
+	if (map->excl_prog_sha) {
+		err = -EPERM;
+		goto put_map;
+	}
 
 	if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
 	    map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH ||
-- 
2.43.0

Re: [PATCH bpf-next 1/4] bpf: Reject exclusive maps for bpf_map_elem iterators

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Generic BPF map iterators bypass BPF_F_RDONLY_PROG and map->frozen protections.
- [High] Incomplete fix for exclusive map security bypass via dynamic attach points
--

commit 9a17d32567844f5c82567e8f969e7dc780b8275c
Author: Daniel Borkmann <daniel@iogearbox.net>

bpf: Reject exclusive maps for bpf_map_elem iterators

Exclusive maps are meant to be reachable only from the single program whose
hash matches. This patch adds a check in bpf_iter_attach_map() to reject
exclusive maps when binding to a bpf_map_elem iterator.

> diff --git a/kernel/bpf/map_iter.c b/kernel/bpf/map_iter.c
> index 261a03ea73d34..ae0741a09c6de 100644
> --- a/kernel/bpf/map_iter.c
> +++ b/kernel/bpf/map_iter.c
> @@ -112,6 +112,10 @@ static int bpf_iter_attach_map(struct bpf_prog *prog,
>  	map = bpf_map_get_with_uref(linfo->map.map_fd);
>  	if (IS_ERR(map))
>  		return PTR_ERR(map);
> +	if (map->excl_prog_sha) {
> +		err = -EPERM;
> +		goto put_map;
> +	}

[Severity: High]
This isn't a bug introduced by this patch, but while enforcing the
excl_prog_sha restriction here, are there other dynamic attach points that
still miss this check?

For example, looking at bpf_iter_attach_map() in net/core/bpf_sk_storage.c,
it binds a map to an sk_storage iterator without checking map->excl_prog_sha:

net/core/bpf_sk_storage.c:bpf_iter_attach_map() {
    ...
	map = bpf_map_get_with_uref(linfo->map.map_fd);
	if (IS_ERR(map))
		return PTR_ERR(map);
    ...
}

Similarly, sock_map_iter_attach_target(), sock_map_link_create(), and
sock_map_get_from_fd() in net/core/sock_map.c dynamically attach BPF programs
or iterators to sockmaps but do not appear to check map->excl_prog_sha.

Could these missing checks allow the attachment of an untrusted program or
iterator to an exclusive sk_storage or sockmap, bypassing the exclusivity
constraint?

[Severity: Critical]
This is also a pre-existing issue, but does this function properly enforce
read-only constraints on maps?

Later in this same function, the code checks if the iterator program's
max_rdwr_access exceeds the map's value_size:

kernel/bpf/map_iter.c:bpf_iter_attach_map() {
    ...
	key_acc_size = prog->aux->max_rdonly_access;
	value_acc_size = prog->aux->max_rdwr_access;
    ...
	if (key_acc_size > key_size || value_acc_size > value_size) {
		err = -EACCES;
		goto put_map;
	}
    ...
}

However, it does not appear to check if the target map has the
BPF_F_RDONLY_PROG flag or if map->frozen is set.

Since the BPF verifier defines the bpf_map_elem iterator program argument
ctx->value as PTR_TO_BUF (without MEM_RDONLY), it allows the iterator program
to write to the map element.

If an iterator is attached to a read-only or frozen map (like a .rodata array
map), can it bypass these protections and modify the contents dynamically?
Because the verifier assumes these maps are immutable and optimizes bounds
checks based on their contents, could this lead to out-of-bounds memory
accesses in previously verified BPF programs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602133052.423725-1-daniel@iogearbox.net?part=1

Re: [PATCH bpf-next 1/4] bpf: Reject exclusive maps for bpf_map_elem iterators

[Daniel Borkmann]

On 6/2/26 3:49 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [Critical] Generic BPF map iterators bypass BPF_F_RDONLY_PROG and map->frozen protections.
> - [High] Incomplete fix for exclusive map security bypass via dynamic attach points
These are two pre-existing issues and not relevant for the integrity of signed loaders
which this patch series addresses.

The exclusivity guarantee ("only the hash-matching program may touch this map") as a
concept outside of signing may be worth to fix the sk_storage.. The iterators one being
able to write into frozen/RDONLY_PROG maps is an issue as well given verifier treats
these as known constants. I'll add them to my todo list.

[PATCH bpf-next 2/4] libbpf: Guard add_data() against size overflow

[Daniel Borkmann]

add_data() computes size8 = roundup(size, 8) and then hands size8 to
realloc_data_buf() before doing memcpy(gen->data_cur, data, size) with
the original size. A wrapped size8 passes through the realloc_data_buf()
INT32_MAX check. Harden this against overflow, though not realistic to
happen in practice.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
 tools/lib/bpf/gen_loader.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
index 66e13566bc31..d79695f01c87 100644
--- a/tools/lib/bpf/gen_loader.c
+++ b/tools/lib/bpf/gen_loader.c
@@ -160,10 +160,16 @@ void bpf_gen__init(struct bpf_gen *gen, int log_level, int nr_progs, int nr_maps
 
 static int add_data(struct bpf_gen *gen, const void *data, __u32 size)
 {
-	__u32 size8 = roundup(size, 8);
 	__u64 zero = 0;
+	__u32 size8;
 	void *prev;
 
+	if (size > INT32_MAX) {
+		gen->error = -ERANGE;
+		return 0;
+	}
+	size8 = roundup(size, 8);
+
 	if (realloc_data_buf(gen, size8))
 		return 0;
 	prev = gen->data_cur;
-- 
2.43.0

[PATCH bpf-next 3/4] selftests/bpf: Keep verifier_map_ptr exercising ops pointer access

[Daniel Borkmann]

sashiko complained that 38498c0ebacd ("selftests/bpf: Adjust verifier_map_ptr
for the map's excl field") would slightly decrease the test coverage given
before the test was against the verifier rejecting the ops pointer. Recover
the old test with the right offsets and add the existing one as an additional
test case.

  # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_map_ptr
  [    1.672932] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel
  #637/1   verifier_map_ptr/bpf_map_ptr: read with negative offset rejected:OK
  #637/2   verifier_map_ptr/bpf_map_ptr: read with negative offset rejected @unpriv:OK
  #637/3   verifier_map_ptr/bpf_map_ptr: write rejected:OK
  #637/4   verifier_map_ptr/bpf_map_ptr: write rejected @unpriv:OK
  #637/5   verifier_map_ptr/bpf_map_ptr: read non-existent field rejected:OK
  #637/6   verifier_map_ptr/bpf_map_ptr: read non-existent field rejected @unpriv:OK
  #637/7   verifier_map_ptr/bpf_map_ptr: read beyond excl field rejected:OK
  #637/8   verifier_map_ptr/bpf_map_ptr: read beyond excl field rejected @unpriv:OK
  #637/9   verifier_map_ptr/bpf_map_ptr: read ops field accepted:OK
  #637/10  verifier_map_ptr/bpf_map_ptr: read ops field accepted @unpriv:OK
  #637/11  verifier_map_ptr/bpf_map_ptr: r = 0, map_ptr = map_ptr + r:OK
  #637/12  verifier_map_ptr/bpf_map_ptr: r = 0, map_ptr = map_ptr + r @unpriv:OK
  #637/13  verifier_map_ptr/bpf_map_ptr: r = 0, r = r + map_ptr:OK
  #637/14  verifier_map_ptr/bpf_map_ptr: r = 0, r = r + map_ptr @unpriv:OK
  #637     verifier_map_ptr:OK
  [...]
  Summary: 2/20 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
 .../selftests/bpf/progs/verifier_map_ptr.c    | 34 ++++++++++++++++---
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/bpf/progs/verifier_map_ptr.c b/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
index d8e822d1a8ba..166193659870 100644
--- a/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
+++ b/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
@@ -72,17 +72,43 @@ __naked void bpf_map_ptr_write_rejected(void)
 
 /*
  * struct bpf_map starts with the SHA256 hash sha[32] at offset 0 (a readable
- * byte array), followed by the u32 excl field at offset 32. Reading a u32 at
- * offset 33 runs past the end of excl and is rejected.
+ * byte array), the u32 excl field at offset 32, and the ops pointer at offset
+ * 40. Reading a u32 at offset 41 reaches into the middle of the ops pointer,
+ * i.e. a partial pointer access, which is rejected.
  */
 SEC("socket")
 __description("bpf_map_ptr: read non-existent field rejected")
 __failure
-__msg("access beyond the end of member excl (mend:36) in struct bpf_map with off 33 size 4")
+__msg("cannot access ptr member ops with moff 40 in struct bpf_map with off 41 size 4")
 __failure_unpriv
 __msg_unpriv("access is allowed only to CAP_PERFMON and CAP_SYS_ADMIN")
 __flag(BPF_F_ANY_ALIGNMENT)
 __naked void read_non_existent_field_rejected(void)
+{
+	asm volatile ("					\
+	r6 = 0;						\
+	r1 = %[map_array_48b] ll;			\
+	r6 = *(u32*)(r1 + 41);				\
+	r0 = 1;						\
+	exit;						\
+"	:
+	: __imm_addr(map_array_48b)
+	: __clobber_all);
+}
+
+/*
+ * The u32 excl field spans offsets 32..35 (mend 36). Reading a u32 at offset
+ * 33 starts inside excl but extends past its end, which the verifier rejects
+ * as an out-of-bounds scalar access.
+ */
+SEC("socket")
+__description("bpf_map_ptr: read beyond excl field rejected")
+__failure
+__msg("access beyond the end of member excl (mend:36) in struct bpf_map with off 33 size 4")
+__failure_unpriv
+__msg_unpriv("access is allowed only to CAP_PERFMON and CAP_SYS_ADMIN")
+__flag(BPF_F_ANY_ALIGNMENT)
+__naked void read_beyond_excl_field_rejected(void)
 {
 	asm volatile ("					\
 	r6 = 0;						\
@@ -105,7 +131,7 @@ __naked void ptr_read_ops_field_accepted(void)
 	asm volatile ("					\
 	r6 = 0;						\
 	r1 = %[map_array_48b] ll;			\
-	r6 = *(u64*)(r1 + 0);				\
+	r6 = *(u64*)(r1 + 40);				\
 	r0 = 1;						\
 	exit;						\
 "	:
-- 
2.43.0

Re: [PATCH bpf-next 3/4] selftests/bpf: Keep verifier_map_ptr exercising ops pointer access

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Test suite regression on 32-bit architectures due to hardcoded 64-bit struct offsets.
--

commit 3edf5d52e70729a68d2f02df9f51787362f009a3
Author: Daniel Borkmann <daniel@iogearbox.net>

selftests/bpf: Keep verifier_map_ptr exercising ops pointer access

This commit recovers the old test for verifier_map_ptr with the right
offsets to exercise ops pointer access. It also adds the existing test
as an additional test case.

> diff --git a/tools/testing/selftests/bpf/progs/verifier_map_ptr.c b/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
> index d8e822d1a8bab..1661936598703 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
[ ... ]
> @@ -72,17 +72,43 @@ __naked void bpf_map_ptr_write_rejected(void)
[ ... ]
>  __description("bpf_map_ptr: read non-existent field rejected")
>  __failure
> -__msg("access beyond the end of member excl (mend:36) in struct bpf_map with off 33 size 4")
> +__msg("cannot access ptr member ops with moff 40 in struct bpf_map with off 41 size 4")
>  __failure_unpriv
>  __msg_unpriv("access is allowed only to CAP_PERFMON and CAP_SYS_ADMIN")
>  __flag(BPF_F_ANY_ALIGNMENT)
>  __naked void read_non_existent_field_rejected(void)
> +{
> +	asm volatile ("					\
> +	r6 = 0;						\
> +	r1 = %[map_array_48b] ll;			\
> +	r6 = *(u32*)(r1 + 41);				\

[Severity: Medium]
Does this hardcoded offset in read_non_existent_field_rejected() cause test
failures on 32-bit architectures?

Since pointers are 4 bytes long on 32-bit, the excl field at offset 32
would be followed by ops at offset 36. Offset 41 would point inside
inner_map_meta instead, causing the verifier error message to mismatch
the expected __msg above.

[ ... ]
> @@ -105,7 +131,7 @@ __naked void ptr_read_ops_field_accepted(void)
>  	asm volatile ("					\
>  	r6 = 0;						\
>  	r1 = %[map_array_48b] ll;			\
> -	r6 = *(u64*)(r1 + 0);				\
> +	r6 = *(u64*)(r1 + 40);				\

[Severity: Medium]
Will reading 8 bytes at offset 40 in ptr_read_ops_field_accepted() fail on
32-bit architectures?

On 32-bit, offset 40 corresponds to inner_map_meta which is only 4 bytes.
The verifier requires an exact size match for pointer reads, so a size 8
read would trigger a rejection instead of the expected success.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602133052.423725-1-daniel@iogearbox.net?part=3

[PATCH bpf-next 4/4] selftests/bpf: Test that exclusive maps are rejected as iter targets

[Daniel Borkmann]

Add a subtest to map_excl that creates an exclusive map and verifies a
bpf_map_elem iterator cannot be attached to it, which would otherwise
let an unrelated program read and overwrite the map's contents through
the iterator's writable value buffer.

  # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t map_excl
  [...]
  ./test_progs -t map_excl
  [    1.704382] bpf_testmod: loading out-of-tree module taints kernel.
  [    1.706068] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel
  #215/1   map_excl/map_excl_allowed:OK
  #215/2   map_excl/map_excl_denied:OK
  #215/3   map_excl/map_excl_no_map_in_map:OK
  #215/4   map_excl/map_excl_no_map_iter:OK
  #215     map_excl:OK
  Summary: 1/4 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
 .../selftests/bpf/prog_tests/map_excl.c       | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/map_excl.c b/tools/testing/selftests/bpf/prog_tests/map_excl.c
index a213dd559aae..3088668e2e45 100644
--- a/tools/testing/selftests/bpf/prog_tests/map_excl.c
+++ b/tools/testing/selftests/bpf/prog_tests/map_excl.c
@@ -7,6 +7,7 @@
 #include <bpf/btf.h>
 
 #include "map_excl.skel.h"
+#include "bpf_iter_bpf_array_map.skel.h"
 
 #ifndef SHA256_DIGEST_SIZE
 #define SHA256_DIGEST_SIZE	32
@@ -89,6 +90,42 @@ static void test_map_excl_no_map_in_map(void)
 	close(excl_fd);
 }
 
+static void test_map_excl_no_map_iter(void)
+{
+	__u8 hash[SHA256_DIGEST_SIZE] = {};
+	LIBBPF_OPTS(bpf_map_create_opts, excl_opts,
+		    .excl_prog_hash = hash,
+		    .excl_prog_hash_size = sizeof(hash));
+	DECLARE_LIBBPF_OPTS(bpf_iter_attach_opts, opts);
+	struct bpf_iter_bpf_array_map *skel = NULL;
+	union bpf_iter_link_info linfo;
+	struct bpf_link *link;
+	int excl_fd;
+
+	excl_fd = bpf_map_create(BPF_MAP_TYPE_ARRAY, "excl_iter", 4, 8, 3, &excl_opts);
+	if (!ASSERT_OK_FD(excl_fd, "create exclusive map"))
+		return;
+
+	skel = bpf_iter_bpf_array_map__open_and_load();
+	if (!ASSERT_OK_PTR(skel, "bpf_iter_bpf_array_map__open_and_load"))
+		goto out;
+
+	memset(&linfo, 0, sizeof(linfo));
+	linfo.map.map_fd = excl_fd;
+	opts.link_info = &linfo;
+	opts.link_info_len = sizeof(linfo);
+
+	link = bpf_program__attach_iter(skel->progs.dump_bpf_array_map, &opts);
+	if (!ASSERT_ERR_PTR(link, "reject exclusive map as iter target")) {
+		bpf_link__destroy(link);
+		goto out;
+	}
+	ASSERT_EQ(libbpf_get_error(link), -EPERM, "iter attach errno");
+out:
+	bpf_iter_bpf_array_map__destroy(skel);
+	close(excl_fd);
+}
+
 void test_map_excl(void)
 {
 	if (test__start_subtest("map_excl_allowed"))
@@ -97,4 +134,6 @@ void test_map_excl(void)
 		test_map_excl_denied();
 	if (test__start_subtest("map_excl_no_map_in_map"))
 		test_map_excl_no_map_in_map();
+	if (test__start_subtest("map_excl_no_map_iter"))
+		test_map_excl_no_map_iter();
 }
-- 
2.43.0

Re: [PATCH bpf-next 0/4] More gen_loader fixes #2

[patchwork-bot+netdevbpf]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:

On Tue,  2 Jun 2026 15:30:48 +0200 you wrote:
> Another small follow-up from the sashiko findings about signed loaders.
> In particular, closing the gap to reject exclusive maps in iterators.
> 
> Daniel Borkmann (4):
>   bpf: Reject exclusive maps for bpf_map_elem iterators
>   libbpf: Guard add_data() against size overflow
>   selftests/bpf: Keep verifier_map_ptr exercising ops pointer access
>   selftests/bpf: Test that exclusive maps are rejected as iter targets
> 
> [...]

Here is the summary with links:
  - [bpf-next,1/4] bpf: Reject exclusive maps for bpf_map_elem iterators
    https://git.kernel.org/bpf/bpf-next/c/3c56ee343f94
  - [bpf-next,2/4] libbpf: Guard add_data() against size overflow
    https://git.kernel.org/bpf/bpf-next/c/7fef1796ec4d
  - [bpf-next,3/4] selftests/bpf: Keep verifier_map_ptr exercising ops pointer access
    https://git.kernel.org/bpf/bpf-next/c/082c41209771
  - [bpf-next,4/4] selftests/bpf: Test that exclusive maps are rejected as iter targets
    https://git.kernel.org/bpf/bpf-next/c/8dedd34122d0

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html