CVE-2026-93174
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A flaw in the Linux kernel could allow certain programs to accidentally read old leftover data from the system's memory.
- Exploitation
- Local Privilege
- Attacker needs
- High Privilege
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability allows user-space programs to read uninitialized kernel heap memory through per-CPU BPF map lookups when the map value size is not a multiple of 8 bytes, due to incomplete copying of padding bytes in copy_map_value_long().
Why it matters to the business
Attackers may obtain sensitive kernel memory contents, potentially leading to further exploitation or leakage of confidential information in systems using BPF maps.
How an attack unfolds
An attacker crafts or uses a per-CPU BPF map with a value size requiring padding, performs a LOOKUP_ELEM operation via UAPI, and receives a buffer containing stale heap data from the unpadded tail.
How to fix it
Update the Linux kernel to a version containing the fix that ensures round_up(map->value_size, 8) is passed to bpf_obj_memcpy() in copy_map_value_long().
How to confirm the fix worked
Verify the kernel source includes the corrected copy_map_value_long() function and test map lookups do not leak padding data.
Typical attack path
- Identify or create a per-CPU BPF map with non-aligned value size
- Invoke BPF_OBJ_LOOKUP_ELEM or similar UAPI calls
- Inspect the returned buffer for data beyond the declared value size
How to detect it
Examine system logs for unusual BPF map operations; check for processes performing frequent lookups on per-CPU maps and analyze returned data for anomalous content.
What your security team should do
- Apply available kernel updates promptly
- Review BPF usage for per-CPU maps
- Monitor kernel security advisories
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|