CVE-2026-80675

HighCVSS 7.1

Published: 28/08/2026(UTC)Updated: 29/08/2026(UTC)Translated: 28/08/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.12%

2th percentile - higher than 2% of all known CVEs

Summary

In libbpf, the signed loader does not ensure that a map is exclusive before validating map->sha. Without exclusivity, another BPF program with map access can mutate the contents after freezing, allowing validation on stale data. The fix adds an exclusivity check.

Risk Assessment

An attacker could exploit the lack of exclusivity to alter map contents after validation, potentially leading to data integrity issues or bypassing security in BPF environments.

Recommendation

Update libbpf to a version containing the fix that enforces map exclusivity in the signed loader. Also ensure the host does not omit this check.

Other vulnerabilities in libbpf

CVE-2022-49030High
In the libbpf library in the Linux kernel, a size overflow issue was found when mapping ringbuf memory. The maximum ringbuf size on x86-64 hosts is 2GB, so 2 * max_entries can overflow u32 when mapping producer and data pages. The fix casts the size of the read-only mmap region to __u64 and checks for overflow during mmap.

Original NVD description (English source)

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 BPF_OBJ_GET_INFO_BY_FD 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.