CVE-2026-74364 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject exclusive maps as inner maps in map-in-map
An exclusive map (created with excl_prog_hash) is bound to a single program by hash: check_map_prog_compatibility() refuses to load any program whose digest does not match map->excl_prog_sha. That check only runs for maps a program references directly, i.e. its used_maps. A map reached at runtime through a map-of-maps is never in used_maps, and bpf_map_meta_equal() does not consider excl_prog_sha, so an exclusive map can be inserted into a non-exclusive outer map and then looked up and mutated by an unrelated program, bypassing the exclusivity guarantee.
For the signed loader this defeats the metadata map exclusivity check added in the signed loader: the cached map->sha[] is validated against
the signed hash while another program on a hostile host rewrites the frozen map's contents through the outer map.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the linux kernel's bpf subsystem and represents a critical flaw in the map-in-map implementation that undermines fundamental security guarantees. The issue stems from how exclusive maps are handled when nested within other maps, specifically when an exclusive map created with the excl_prog_hash flag is used as an inner map within a map-of-maps structure. Exclusive maps are designed to provide strong program binding guarantees by ensuring that only programs with matching SHA256 digests can access and modify the map contents through the check_map_prog_compatibility() function.
The technical flaw occurs because the compatibility checking mechanism only operates on maps that appear directly in a program's used_maps list, which represents the immediate dependencies of a bpf program. When a map is accessed through the hierarchical map-in-map structure at runtime, it bypasses this direct reference validation entirely. The bpf_map_meta_equal() function fails to consider the exclusive program hash (excl_prog_sha) during map metadata comparisons, allowing an exclusive map to be legitimately inserted into a non-exclusive outer map without proper validation. This creates a scenario where unrelated programs can access and mutate the contents of what should be a protected exclusive map through the intermediate outer map layer.
The operational impact of this vulnerability is severe as it completely defeats the security model implemented by the signed loader mechanism designed to protect against malicious modifications. The signed loader was intended to validate that map metadata matches expected cryptographic signatures, but this flaw allows an attacker on a hostile host to bypass these protections entirely. An attacker can exploit this weakness to rewrite the contents of frozen maps through the outer map interface, effectively subverting the exclusivity guarantees that were implemented to prevent unauthorized access patterns. This vulnerability creates a path for privilege escalation and data corruption, particularly in environments where bpf programs are loaded from untrusted sources or where multiple programs operate with different security contexts.
The implications extend beyond simple bypass of access controls into fundamental integrity violations within the kernel's bpf framework. This weakness enables an attacker to manipulate map contents that should remain isolated and protected by program binding restrictions, potentially leading to information disclosure, privilege escalation, or denial of service conditions. The vulnerability directly relates to CWE-284 Access Control Bypass and aligns with ATT&CK techniques involving privilege escalation through kernel vulnerabilities. Mitigation requires ensuring that the bpf_map_meta_equal() function properly validates exclusive map metadata regardless of access path, implementing proper hierarchical validation for nested maps, and strengthening the map-in-map access control mechanisms to prevent indirect access patterns that bypass primary security checks.