From: Leon Hwang <leon.hwang@linux.dev>
To: bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Jiri Olsa <jolsa@kernel.org>,
Emil Tsalapatis <emil@etsalapatis.com>,
Shuah Khan <shuah@kernel.org>, Leon Hwang <leon.hwang@linux.dev>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel-patches-bot@fb.com
Subject: [PATCH bpf 0/2] bpf: Copy per-CPU map value padding in copy_map_value_long()
Date: Wed, 24 Jun 2026 23:51:13 +0800 [thread overview]
Message-ID: <20260624155115.85196-1-leon.hwang@linux.dev> (raw)
Sashiko reported [1]:
This is a pre-existing issue, but does iterating over per-CPU maps expose
uninitialized kernel heap memory?
When working with per-CPU maps, temporary buffers are allocated using kmalloc
without the __GFP_ZERO flag in functions like bpf_iter_init_array_map in
kernel/bpf/arraymap.c:
kernel/bpf/arraymap.c:bpf_iter_init_array_map() {
...
value_buf = kmalloc(buf_size, GFP_USER | __GFP_NOWARN);
...
}
This is also done in kernel/bpf/hashtab.c:bpf_iter_init_hash_map().
If the map contains a BTF record, bpf_obj_memcpy in include/linux/bpf.h
explicitly stops at map->value_size instead of filling the entire rounded-up
size:
include/linux/bpf.h:bpf_obj_memcpy() {
...
memcpy(dst + curr_off, src + curr_off, size - curr_off);
...
}
This fails to overwrite the padding bytes up to round_up(map->value_size, 8).
[1] https://lore.kernel.org/bpf/20260622150844.28C551F000E9@smtp.kernel.org/
===
For example,
struct map_uninit_value {
struct prog_test_ref_kfunc __kptr_untrusted *unref_ptr;
__u32 data;
} __attribute__((packed));
struct {
__uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
__type(key, int);
__type(value, struct map_uninit_value);
__uint(max_entries, 1);
} pcpu_array SEC(".maps");
There are 4 padding bytes in the kernel percpu_array map elements.
When lookup element from 'pcpu_array' map, for each CPU, the 4 padding
bytes memory allocated by syscall.c::map_lookup_elem():kvmalloc() could
be exposed to user space.
Without the fix, the selftest could fail with:
test_map_uninit_mem_exposure:FAIL:zeroed tail bytes unexpected memory
mismatch
actual:
2B 2B 2B 2B
expected:
00 00 00 00
Leon Hwang (2):
bpf: Copy per-CPU map value padding in copy_map_value_long()
selftests/bpf: Verify no non-zeroed kernel heap memory exposure
include/linux/bpf.h | 4 +-
.../bpf/prog_tests/test_map_uninit.c | 68 +++++++++++++++++++
tools/testing/selftests/bpf/progs/map_kptr.c | 12 ++++
3 files changed, 82 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/test_map_uninit.c
--
2.54.0
next reply other threads:[~2026-06-24 15:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 15:51 Leon Hwang [this message]
2026-06-24 15:51 ` [PATCH bpf 1/2] bpf: Copy per-CPU map value padding in copy_map_value_long() Leon Hwang
2026-06-24 15:51 ` [PATCH bpf 2/2] selftests/bpf: Verify no non-zeroed kernel heap memory exposure Leon Hwang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260624155115.85196-1-leon.hwang@linux.dev \
--to=leon.hwang@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-patches-bot@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.