CVE-2026-80675: libbpf: Reject non-exclusive metadata maps in the signed loader
In the Linux kernel, the following vulnerability has been resolved:
libbpf: Reject non-exclusive metadata maps in the signed loader
The loader verifies map->sha against the metadata hash in its instructions. map->sha is calculated when BPFOBJGETINFOBYFD is called on the frozen map.
While the map is frozen, the /signed loader/ must also ensure the map is exclusive, as, without exclusivity (which a hostile host could just omit when loading the loader), another BPF program with map access can mutate the contents afterwards, so the check passes on stale data.
With the extra check as part of the signed loader, it now refuses to move on with map->sha validation if the host set it up wrongly.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for exploitation?
A hostile host must load the signed loader without making its metadata maps exclusive. Another BPF program that has access to such a map must then be able to modify its contents after the map hash has been calculated.
Are correctly configured signed loaders affected?
The issue depends on metadata maps not being exclusive. The resolved loader adds a check that refuses to continue with map hash validation when the host has set up the map without exclusivity.
What should be done if the fix cannot be applied immediately?
Ensure metadata maps used by the signed loader are exclusive and prevent other BPF programs from retaining access to them. This prevents later map mutations from invalidating the assumptions behind the previously calculated hash.