CVE-2026-64353 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Keep dynamic inner array lookups nullable
An ARRAY_OF_MAPS can use an array created with BPF_F_INNER_MAP as its inner map template. A concrete inner array with a different max_entries value can then replace the template.
After a successful outer map lookup, the verifier represents the resulting map pointer using the inner map template. Const-key lookup nullness elision consequently uses the template max_entries even though the runtime helper uses the concrete inner map max_entries.
Do not elide lookup result nullness for maps marked with BPF_F_INNER_MAP, because the template max_entries does not prove that the key is in bounds for the concrete runtime map.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability described affects the Linux kernel's eBPF (extended Berkeley Packet Filter) subsystem, specifically within the BPF_MAP_TYPE_ARRAY_OF_MAPS implementation. This flaw exists in how the kernel handles dynamic inner array lookups when dealing with maps that are marked with the BPF_F_INNER_MAP flag. The issue stems from a discrepancy between compile-time verification and runtime behavior during map operations. When an ARRAY_OF_MAPS is created, it uses a template inner map that defines structural properties including max_entries. However, during runtime execution, concrete inner maps with potentially different max_entries values can replace the template, creating a mismatch in how nullness checking is performed.
The technical root cause resides in the verifier's handling of const-key lookup nullness elision for BPF_F_INNER_MAP flagged maps. During verification, the system represents map pointers using the inner map template properties, which means that when performing nullness analysis for constant key lookups, it incorrectly applies the template's max_entries value rather than the actual concrete inner map's max_entries. This discrepancy occurs because the verifier assumes that if a key is within bounds of the template, it must also be within bounds of the runtime map, which is not necessarily true when the concrete inner map has different sizing parameters.
This vulnerability creates a potential security risk by enabling incorrect nullness assumptions during BPF program execution. The flaw allows for scenarios where programs might incorrectly assume that certain lookups will succeed based on template bounds checking, while in reality the actual runtime inner map could have different size constraints that would cause legitimate failures. This misalignment between verification and execution behavior can lead to unexpected program termination or potentially exploitable conditions where memory access patterns differ from what was verified. The issue particularly affects programs that rely on dynamic inner array lookups within ARRAY_OF_MAPS structures, where the template-based bounds checking fails to account for runtime map-specific sizing.
The operational impact of this vulnerability extends beyond simple correctness issues into potential security implications for systems relying on eBPF for kernel-level operations and network filtering. Attackers could potentially craft BPF programs that exploit this discrepancy to bypass intended access controls or cause denial-of-service conditions through carefully constructed array lookups. The vulnerability affects any system running Linux kernels with eBPF support where ARRAY_OF_MAPS are used, particularly in environments using complex network filtering rules or security monitoring systems that depend on eBPF-based solutions. From a compliance perspective, this issue violates principles outlined in CWE-129 and CWE-131 related to improper input validation and buffer overflow conditions.
Mitigation strategies for this vulnerability involve updating to patched kernel versions where the verifier has been corrected to properly handle BPF_F_INNER_MAP flagged maps by not eliding lookup result nullness for these specific map types. Administrators should prioritize applying kernel updates from their distribution vendors as soon as patches become available. For systems where immediate updates are not possible, limiting the use of ARRAY_OF_MAPS with BPF_F_INNER_MAP flags in critical security-sensitive applications can help reduce risk exposure. Additionally, monitoring eBPF program loading and execution patterns can help detect potentially malicious usage of this vulnerability. The fix aligns with ATT&CK techniques related to privilege escalation and defense evasion by ensuring proper verification of kernel-level operations before execution. Organizations should also review their eBPF program deployment practices to ensure proper validation and testing of programs that utilize array-of-maps constructs, particularly in production environments where security is paramount.