Re: [PATCH bpf-next v6 6/8] 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:
- [Medium] Stale test logic in `signed_loader.c` causes selftest suite failure due to removed in-loader metadata checks.
--

--- Patch [6]: [PATCH bpf-next v6 6/8] selftests/bpf: Adjust bpf_map layout in verifier_map_ptr ---
commit 57fd96aa0d68880807526c20a038bd95f1762aa4
Author: Daniel Borkmann <daniel@iogearbox.net>

selftests/bpf: Adjust bpf_map layout in verifier_map_ptr

This patch adjusts the selftest verifier expectations for bpf_map's memory
layout. It updates tests to reflect the removal of the write-only excl member,
moving ops to offset 32 and inner_map_meta to offset 40.

> 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
[ ... ]
> @@ -97,23 +98,23 @@ __naked void read_non_existent_field_rejected(void)
>  }
>  
>  /*
> - * 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
> + * The sha byte array spans offsets 0..31 (mend 32). Reading a u32 at offset

[Severity: Medium]
Since this series removes the excl field and emit_signature_match(), did we
miss updating tools/testing/selftests/bpf/prog_tests/signed_loader.c?

When running test_progs, test_signed_loader() calls metadata_check_shape(),
which fails here because it still expects the loader to read the removed
excl field at offset 32 and relies on emit_signature_match():

check_sig_match_shape() {
	...
	if (!ASSERT_GE(a, 0, "emit_signature_match present"))
		return;
	...
	/* excl check: r2 = *(u32 *)(map + 32); if r2 != 1 goto cleanup */
	ASSERT_EQ(in[a + 2].code, (BPF_LDX | BPF_MEM | BPF_W), "excl load width");
	ASSERT_EQ(in[a + 2].off, SHA256_DIGEST_LENGTH, "excl field offset");
	...
}

Tests like metadata_sha_mismatch also seem to rely on the removed in-loader
hash check to reject tampered maps, meaning they might now unexpectedly run
successfully and fail their ASSERT_EQ(r, -EINVAL) verifications. Can this
cause the selftests suite to fail?

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