CVE-2026-80675

The Linux kernel's BPF signed loader verifies a BPF map's metadata by comparing map->sha against a metadata hash, but it did not require that the metadata map be exclusive. Because the hash is computed when BPF_OBJ_GET_INFO_BY_FD is called on the frozen map, a hostile host or local actor could set up a non-exclusive map that another BPF program with map access can mutate after verification, causing the check to pass on stale data. An attacker with local, low-privileged access in such a setup can defeat the signed loader's integrity verification, gaining high confidentiality and integrity impact (per the CVSS 3.1 score of 7.1) without needing user interaction. Only systems that actually use the BPF signed loader (signed BPF program loading with metadata maps) are affected; ordinary BPF usage without the signed loader is not impacted by this flaw. No public proof-of-concept, CISA KEV listing, or known exploitation has been reported, and EPSS estimates only a 0.1% chance of exploitation in the next 30 days.

What to do: Apply a Linux kernel update that includes the upstream fix 'libbpf: Reject non-exclusive metadata maps in the signed loader' from your distribution's stable/security feed; the data does not specify fixed version numbers, so check your vendor's advisory for the exact package. Operators using the signed loader should verify that their loader/host enforces map exclusivity before relying on map->sha verification, and treat the signed loader's integrity guarantees as weakened until patched. Standard BPF workloads that do not use the signed loader need no immediate action.