CVE-2026-93174 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Copy per-CPU map value padding in copy_map_value_long()
In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer.
However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8).
The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps.
Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy path.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel contains a critical information disclosure vulnerability within its Berkeley Packet Filter (BPF) subsystem, specifically affecting how per-CPU map values are copied to user space via the copy_map_value_long function. This flaw arises from an inconsistency in memory handling between internal kernel structures and the data exposed through User API lookup operations. Per-CPU maps store their elements with a size that is rounded up to the nearest eight-byte boundary, ensuring proper alignment for performance and hardware requirements. However, when performing lookups via UAPI paths such as BPF_MAP_LOOKUP_ELEM or related variants, the system allocates temporary buffers without zeroing them out using the __GFP_ZERO flag. This allocation strategy relies on the assumption that all necessary data will be explicitly copied into these buffers before being returned to user space.
The technical root cause lies in the copy_map_value_long function passing only map->value_size to bpf_obj_memcpy rather than the rounded-up size. While this distinction is negligible for maps without special fields, it becomes critical when per-CPU maps contain specific data structures that trigger alternative copying paths within bpf_obj_memcpy. In these scenarios, the function utilizes standard memcpy operations which strictly adhere to the provided length parameter. Consequently, any tail padding between map->value_size and round_up(map->value_size, 8) is skipped during the copy process. Since the destination buffer was not initialized with zeros, this omission leaves uninitialized memory regions within the temporary buffer intact. These regions retain whatever data previously occupied that heap space, creating a direct pathway for stale kernel information to leak into user-space applications.
The operational impact of this vulnerability allows local users or processes with appropriate BPF permissions to read arbitrary kernel heap contents. By repeatedly querying per-CPU maps where the value size is not aligned to eight bytes, an attacker can systematically extract sensitive data from previous allocations in the same memory region. This information disclosure can potentially reveal cryptographic keys, authentication tokens, process identifiers, or other confidential state stored within the kernel's dynamic memory pool. The vulnerability also extends to bpf_iter operations involving per-CPU maps, broadening the attack surface beyond simple map lookups to include iteration-based data retrieval mechanisms. Such leaks undermine the security isolation guarantees provided by the BPF subsystem and can facilitate further exploitation chains that rely on knowledge of internal kernel structures or secrets.
This issue is classified under CWE-200 as an Information Exposure vulnerability, specifically falling into categories related to exposure of sensitive information through error messages or improper memory handling. From a threat modeling perspective aligned with MITRE ATT&CK techniques, this represents T1537, which involves communication via application layer protocols where the attacker extracts data from internal systems without direct access to storage media. The vulnerability highlights the importance of strict boundary enforcement in kernel-space memory operations and the risks associated with non-zeroed temporary buffers used for inter-process communication.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that corrects the length parameter passed to bpf_obj_memcpy within copy_map_value_long. By ensuring that round_up(map->value_size, 8) is consistently used regardless of special field presence, the entire per-CPU slot including padding is copied into the temporary buffer. This eliminates the gap where stale data could remain unoverwritten. Additionally, system administrators should ensure their kernels are updated to versions containing this fix. For environments unable to patch immediately, restricting BPF map access privileges and auditing for unusual patterns in bpf syscall usage can help mitigate exposure risks until a full remediation is deployed.