From: Leon Hwang <leon.hwang@linux.dev>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net,
martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
yonghong.song@linux.dev, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
jolsa@kernel.org, memxor@gmail.com, linux-kernel@vger.kernel.org,
kernel-patches-bot@fb.com, Leon Hwang <leon.hwang@linux.dev>
Subject: [PATCH bpf v2 0/4] bpf: Fix possible memleak when updating hash and local storage maps
Date: Tue, 21 Oct 2025 00:46:04 +0800 [thread overview]
Message-ID: <20251020164608.20536-1-leon.hwang@linux.dev> (raw)
In the discussion thread
"[PATCH bpf-next v9 0/7] bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags for percpu maps"[1],
it was pointed out that missing calls to bpf_obj_free_fields() could
lead to memory leaks.
A selftest was added to confirm that this is indeed a real issue - the
memory referenced by BPF_KPTR_{REF,PERCPU} fields is not freed when
bpf_obj_free_fields() is missing after copy_map_value[,_long]().
Further inspection of copy_map_value[,_long]() call sites revealed two
locations affected by this issue:
1. pcpu_copy_value()
2. htab_map_update_elem() when used with BPF_F_LOCK
This series fixes the leaks by properly calling bpf_obj_free_fields()
(or check_and_free_fields()) after copy_map_value[,_long]() and adds
selftests to verify the fix.
Changes:
v1 -> v2:
* Add test to verify no memleak when updating cgroup local storage maps.
* Address review from AI bot:
* Fast path without bucket lock (around line 610) in
'bpf_local_storage.c'.
v1: https://lore.kernel.org/bpf/20251016145801.47552-1-leon.hwang@linux.dev/
Links:
[1] https://lore.kernel.org/bpf/20250930153942.41781-1-leon.hwang@linux.dev/
Leon Hwang (4):
bpf: Fix possible memleak in [lru_,]percpu_hash map update
bpf: Fix possible memleak when updating hash maps with BPF_F_LOCK
bpf: Fix possible memleak when updating local storage maps with
BPF_F_LOCK
selftests/bpf: Add tests to verify no memleak when updating hash and
cgrp storage maps
kernel/bpf/bpf_local_storage.c | 1 +
kernel/bpf/hashtab.c | 4 +
.../bpf/prog_tests/refcounted_kptr.c | 167 +++++++++++++++++-
.../selftests/bpf/progs/refcounted_kptr.c | 160 +++++++++++++++++
4 files changed, 331 insertions(+), 1 deletion(-)
--
2.51.0
next reply other threads:[~2025-10-20 16:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-20 16:46 Leon Hwang [this message]
2025-10-20 16:46 ` [PATCH bpf v2 1/4] bpf: Fix possible memleak in [lru_,]percpu_hash map update Leon Hwang
2025-10-20 16:46 ` [PATCH bpf v2 2/4] bpf: Fix possible memleak when updating hash maps with BPF_F_LOCK Leon Hwang
2025-10-20 16:46 ` [PATCH bpf v2 3/4] bpf: Fix possible memleak when updating local storage " Leon Hwang
2025-10-20 16:46 ` [PATCH bpf v2 4/4] selftests/bpf: Add tests to verify no memleak when updating hash and cgrp storage maps 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=20251020164608.20536-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=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-patches-bot@fb.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=sdf@fomichev.me \
--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.