[PATCH bpf v3 2/2] bpf, libbpf: reject non-exclusive metadata maps in the signed loader
Alexei Starovoitov
alexei.starovoitov at gmail.com
Sat May 23 15:12:42 UTC 2026
On Fri, May 22, 2026 at 11:53 PM KP Singh <kpsingh at kernel.org> wrote:
>
> The loader verifies map->sha against the metadata hash in its
> instructions. map->sha is calculated when BPF_OBJ_GET_INFO_BY_FD is called
> on the frozen map.
>
> While the map is frozen, the loader must also ensure the map is
> exclusive, as, without exclusivity, another BPF program with map access
> can mutate the contents afterwards, so the check passes on stale data.
Hold on. How is this an issue? excl_prog_sha guarantees
that only loader prog can use this map.
Are you saying the same loader prog will use the same map
for the 2nd time. Ok. I still don't see a problem.
> Place excl_prog_sha right after sha[] in struct bpf_map and have
> gen_loader bail with -EINVAL when it is NULL, via BPF_PSEUDO_MAP_IDX at
> fixed offset 32. 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).
I don't think we can go from maybe-racy to certainly-broken-on-32-bit.
So only applied patch 1.
More information about the Linux-security-module-archive
mailing list