Re: [PATCH bpf-next v4 7/9] selftests/bpf: Adjust bpf_map layout in verifier_map_ptr

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The removal of the `excl` field from `struct bpf_map` breaks backwards compatibility for existing, previously compiled userspace signed BPF loaders (light skeletons).
--

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

selftests/bpf: Adjust bpf_map layout in verifier_map_ptr

This commit updates the verifier_map_ptr selftest to reflect the new layout
of struct bpf_map. It adjusts the offsets and expected error messages to
account for the ops pointer moving to offset 32 after the removal of the
excl field.

> diff --git a/tools/testing/selftests/bpf/progs/verifier_map_ptr.c b/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
> index 1661936598703..e0a65835c861b 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_map_ptr.c
> @@ -72,14 +72,15 @@ __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), 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.
> + * struct bpf_map starts with the SHA256 hash sha[32] at offset 0 (a readable
> + * byte array), followed by the ops pointer at offset 32 and the inner_map_meta
> + * pointer at offset 40. Reading a u32 at offset 41 reaches into the middle of
> + * the inner_map_meta pointer, i.e. a partial pointer access, which is
> + * rejected.
>   */
[Severity: Critical]
Does this structure layout change introduce a regression by breaking backwards
compatibility for existing userspace signed BPF loaders (light skeletons)?

Older versions of bpftool generated a loader program that included explicit
BPF bytecode to verify the metadata map via a 4-byte read of the excl field
at offset 32. To support this, the kernel previously pinned this offset using
BUILD_BUG_ON(offsetof(struct bpf_map, excl) != SHA256_DIGEST_SIZE).

By removing excl without retaining 4 bytes of padding, the 8-byte ops pointer
shifts to offset 32 in struct bpf_map. When an old loader attempts to read 4
bytes at offset 32, the verifier sees a partial pointer read (since 8 != 4)
and unconditionally rejects it:

kernel/bpf/btf.c:btf_struct_access() {
    ...
    if (msize != size || off != moff) {
        bpf_log(log,
            "cannot access ptr member %s with moff %u in struct %s with off %u size %u\n",
            mname, moff, tname, off, size);
        return -EACCES;
    }
    ...
}

Could a 4-byte padding be added to maintain backward compatibility, allowing
old loaders to safely read the padding while the new kernel securely handles
the load-time verification?

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