[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251016145801.47552-1-leon.hwang@linux.dev>
Date: Thu, 16 Oct 2025 22:57:58 +0800
From: Leon Hwang <leon.hwang@...ux.dev>
To: bpf@...r.kernel.org
Cc: ast@...nel.org,
andrii@...nel.org,
daniel@...earbox.net,
martin.lau@...ux.dev,
eddyz87@...il.com,
song@...nel.org,
yonghong.song@...ux.dev,
john.fastabend@...il.com,
kpsingh@...nel.org,
sdf@...ichev.me,
haoluo@...gle.com,
jolsa@...nel.org,
memxor@...il.com,
linux-kernel@...r.kernel.org,
kernel-patches-bot@...com,
Leon Hwang <leon.hwang@...ux.dev>
Subject: [PATCH bpf 0/3] bpf: Fix possible memleak when updating hash maps
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 two
selftests to verify the fix.
Link:
[1] https://lore.kernel.org/bpf/20250930153942.41781-1-leon.hwang@linux.dev/
Leon Hwang (3):
bpf: Fix possible memleak in [lru_,]percpu_hash map update
bpf: Fix possible memleak when updating hash maps with BPF_F_LOCK
selftests/bpf: Add test to verify no memleak when updating hash maps
kernel/bpf/hashtab.c | 4 +
.../bpf/prog_tests/refcounted_kptr.c | 93 ++++++++++++++++
.../selftests/bpf/progs/refcounted_kptr.c | 101 ++++++++++++++++++
3 files changed, 198 insertions(+)
--
2.51.0
Powered by blists - more mailing lists