[PATCH v2 2/2] bpf, libbpf: reject non-exclusive metadata maps in the signed loader

[bot+bpf-ci at kernel.org]

> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 1b28cacc3075..5f1ed0823892 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -295,6 +295,7 @@ struct bpf_map_owner {
>
>  struct bpf_map {
>  	u8 sha[SHA256_DIGEST_SIZE];
> +	__bpf_md_ptr(char *, excl_prog_sha);
>  	const struct bpf_map_ops *ops;
>  	struct bpf_map *inner_map_meta;
>  #ifdef CONFIG_SECURITY
> @@ -335,7 +336,6 @@ struct bpf_map {
>  	atomic64_t sleepable_refcnt;
>  	s64 __percpu *elem_count;
>  	u64 cookie; /* write-once */
> -	char *excl_prog_sha;
>  };

[ ... ]

> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> index 9478b8f78f26..fee35c26deb8 100644
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c
> @@ -600,6 +600,22 @@ static void emit_signature_match(struct bpf_gen *gen)
>  			gen->error = -ERANGE;
>  		}
>  	}
> +
> +	/* Reject if the metadata map is not exclusive. Without exclusivity
> +	 * the cached map->sha[] verified above can be stale: another BPF
> +	 * program with map access could have mutated the contents between
> +	 * BPF_OBJ_GET_INFO_BY_FD and loader execution.
> +	 */

This isn't a bug, but the multi-line comment opening should follow the
BPF subsystem style with /* on its own line.

> +	emit2(gen, BPF_LD_IMM64_RAW_FULL(BPF_REG_1, BPF_PSEUDO_MAP_IDX,
> +					 0, 0, 0, 0));
> +	emit(gen, BPF_LDX_MEM(BPF_DW, BPF_REG_2, BPF_REG_1, SHA256_DWORD_SIZE * sizeof(__u64)));
> +	off = -(gen->insn_cur - gen->insn_start - gen->cleanup_label) / 8 - 2;
> +	if (is_simm16(off)) {
> +		emit(gen, BPF_MOV64_IMM(BPF_REG_7, -EINVAL));
> +		emit(gen, BPF_JMP_IMM(BPF_JEQ, BPF_REG_2, 0, off));
> +	} else {
> +		gen->error = -ERANGE;
> +	}
>  }

[ ... ]

> diff --git a/tools/testing/selftests/bpf/progs/verifier_map_ptr.c b/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
> index e2767d27d8aa..baef2e93cb41 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
> @@ -70,13 +70,15 @@ __naked void bpf_map_ptr_write_rejected(void)
>  	: __clobber_all);
>  }
>
> -/* The first element of struct bpf_map is a SHA256 hash of 32 bytes, accessing
> - * into this array is valid. The opts field is now at offset 33.
> +/* The first 32 bytes of struct bpf_map are the SHA256 hash; accessing into
> + * this array is valid. excl_prog_sha follows at offset 32 (8 bytes via
> + * __bpf_md_ptr), then ops at offset 40. Reading at offset 41 crosses into
> + * the ops pointer and must be rejected.
>   */
>  SEC("socket")
>  __description("bpf_map_ptr: read non-existent field rejected")
>  __failure
> -__msg("cannot access ptr member ops with moff 32 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)
> @@ -85,7 +87,7 @@ __naked void read_non_existent_field_rejected(void)
>  	asm volatile ("					\
>  	r6 = 0;						\
>  	r1 = %[map_array_48b] ll;			\
> -	r6 = *(u32*)(r1 + 33);				\
> +	r6 = *(u32*)(r1 + 41);				\
>  	r0 = 1;						\
>  	exit;						\
>  "	:


---
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/26236267798