summaryrefslogtreecommitdiff
path: root/include/uapi
diff options
context:
space:
mode:
authorLeon Hwang <leon.hwang@linux.dev>2026-06-24 23:51:14 +0800
committerAndrii Nakryiko <andrii@kernel.org>2026-07-01 11:27:37 -0700
commit7cf9cd98cf6f0df3befc167ca6b54c07014d71de (patch)
treeba9f785e6eebb69e564a0c77bab006114e693fe0 /include/uapi
parentf29997a6d920cdfa2c43995e17c596c599ff261b (diff)
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. Fixes: 448325199f57 ("bpf: Add copy_map_value_long to copy to remote percpu memory") Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260624155115.85196-2-leon.hwang@linux.dev
Diffstat (limited to 'include/uapi')
0 files changed, 0 insertions, 0 deletions