CVE-2026-93174: bpf: Copy per-CPU map value padding in copy_map_value_long()
In the Linux kernel, the following vulnerability has been resolved:
bpf: Copy per-CPU map value padding in copymapvaluelong()
In kernel, per-CPU map elements are stored with roundup(map->valuesize, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer.
However, copymapvaluelong() passes 'map->valuesize' to bpfobjmemcpy(). When the map has special fields, bpfobjmemcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->valuesize' and roundup(map->valuesize, 8).
The temporary UAPI lookup buffers are allocated without GFPZERO. As a result, when the per-CPU map's value size is not equal to roundup(map->valuesize, 8), UAPI LOOKUPELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpfiter for per-CPU maps.
Pass roundup(map->valuesize, 8) to bpfobjmemcpy() from copymapvaluelong(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant roundup() from bpfobjmemcpy()'s longmemcpy path.
Affected Software
Event History
Frequently Asked Questions
When can this leak occur?
The issue affects per-CPU BPF maps whose value size is not already a multiple of 8 bytes and that contain special fields. It can occur through UAPI LOOKUP_ELEM operations and their variants, as well as through bpf_iter for per-CPU maps.
What information could be exposed?
Affected lookup paths can return stale kernel heap contents from the padding between the map value size and its 8-byte-rounded per-CPU storage size. The exposed bytes are the uninitialized tail padding in the temporary UAPI lookup buffer.
What change fixes the issue?
The fix copies round_up(map->value_size, 8) bytes for each per-CPU slot in copy_map_value_long(), including padding. This ensures the entire stored slot is copied before data is returned through the affected paths.