[PATCH bpf v3 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 cd191c5fdb0a..11bec73db199 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];
> +	char *excl_prog_sha;

Daniel Borkmann suggested adding BUILD_BUG_ON checks to validate the
struct layout assumptions that gen_loader relies on. Specifically:

  BUILD_BUG_ON(offsetof(struct bpf_map, sha) != 0);
  BUILD_BUG_ON(offsetof(struct bpf_map, excl_prog_sha) != SHA256_DIGEST_SIZE);
  BUILD_BUG_ON(sizeof_field(struct bpf_map, excl_prog_sha) != sizeof(__u64));

Would this make the code more robust against future struct layout changes?

>  	const struct bpf_map_ops *ops;
>  	struct bpf_map *inner_map_meta;
>  #ifdef CONFIG_SECURITY

[ ... ]

> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> index 9478b8f78f26..5077472b9fd2 100644
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c
> @@ -600,6 +600,23 @@ 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.
> +	 */
> +	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)));

Will this BPF_DW (8-byte) read pass the BPF verifier on 32-bit
architectures?

Sashiko AI flagged this in v2, and you confirmed through testing on a
32-bit kernel that the verifier rejects this with 'cannot access ptr
member excl_prog_sha with moff 0 in struct (anon) with off 0 size 8'.
The issue is that __bpf_md_ptr doesn't emit padding in BTF; the kernel's
BTF represents the pointer member with a size of 4 bytes on 32-bit
systems, while btf_struct_walk() enforces exact size matching.

The commit message acknowledges this: 'The 8-byte read of the pointer
field limits this to 64-bit kernels; gen_loader needs target pointer
size tracking to emit the right sized read on 32-bit (follow-up).'

This means the security check will be silently bypassed on 32-bit
systems until the follow-up is implemented.

Could SHA256_DIGEST_SIZE be used here instead of 'SHA256_DWORD_SIZE *
sizeof(__u64)'? Daniel Borkmann pointed out that SHA256_DWORD_SIZE is
already SHA256_DIGEST_SIZE / sizeof(__u64), so the multiplication
essentially reconstructs SHA256_DIGEST_SIZE.

> +	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;
> +	}
>  }

[ ... ]

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