kernel/linux.git/tools/lib/bpf/libbpf.c, branch v6.12.80

libbpf: Fix -Wdiscarded-qualifiers under C23

2026-02-06T15:55:49+00:00

commit d70f79fef65810faf64dbae1f3a1b5623cdb2345 upstream. glibc ≥ 2.42 (GCC 15) defaults to -std=gnu23, which promotes -Wdiscarded-qualifiers to an error. In C23, strstr() and strchr() return "const char *". Change variable types to const char * where the pointers are never modified (res, sym_sfx, next_path). Suggested-by: Florian Weimer Suggested-by: Andrii Nakryiko Signed-off-by: Mikhail Gavrilov Link: https://lore.kernel.org/r/20251206092825.1471385-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Alexei Starovoitov [ shung-hsi.yu: needed to fix kernel build failure due to libbpf since glibc 2.43+ (which adds 'const' qualifier to strstr). 'sym_sfx' hunk dropped because commit f8a05692de06 ("libbpf: Work around kernel inconsistently stripping '.llvm.' suffix") is not present. ] Signed-off-by: Shung-Hsi Yu Signed-off-by: Greg Kroah-Hartman

libbpf: Fix error when st-prefix_ops and ops from differ btf

2025-10-15T10:00:04+00:00

[ Upstream commit 0cc114dc358cf8da2ca23a366e761e89a46ca277 ] When a module registers a struct_ops, the struct_ops type and its corresponding map_value type ("bpf_struct_ops_") may reside in different btf objects, here are four possible case: +--------+---------------+-------------+---------------------------------+ | |bpf_struct_ops_| xxx_ops | | +--------+---------------+-------------+---------------------------------+ | case 0 | btf_vmlinux | btf_vmlinux | be used and reg only in vmlinux | +--------+---------------+-------------+---------------------------------+ | case 1 | btf_vmlinux | mod_btf | INVALID | +--------+---------------+-------------+---------------------------------+ | case 2 | mod_btf | btf_vmlinux | reg in mod but be used both in | | | | | vmlinux and mod. | +--------+---------------+-------------+---------------------------------+ | case 3 | mod_btf | mod_btf | be used and reg only in mod | +--------+---------------+-------------+---------------------------------+ Currently we figure out the mod_btf by searching with the struct_ops type, which makes it impossible to figure out the mod_btf when the struct_ops type is in btf_vmlinux while it's corresponding map_value type is in mod_btf (case 2). The fix is to use the corresponding map_value type ("bpf_struct_ops_") as the lookup anchor instead of the struct_ops type to figure out the `btf` and `mod_btf` via find_ksym_btf_id(), and then we can locate the kern_type_id via btf__find_by_name_kind() with the `btf` we just obtained from find_ksym_btf_id(). With this change the lookup obtains the correct btf and mod_btf for case 2, preserves correct behavior for other valid cases, and still fails as expected for the invalid scenario (case 1). Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support") Signed-off-by: D. Wythe Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20250926071751.108293-1-alibuda@linux.alibaba.com Signed-off-by: Sasha Levin

libbpf: Fix reuse of DEVMAP

2025-10-15T09:59:56+00:00

[ Upstream commit 6c6b4146deb12d20f42490d5013f2043df942161 ] Previously, re-using pinned DEVMAP maps would always fail, because get_map_info on a DEVMAP always returns flags with BPF_F_RDONLY_PROG set, but BPF_F_RDONLY_PROG being set on a map during creation is invalid. Thus, ignore the BPF_F_RDONLY_PROG flag in the flags returned from get_map_info when checking for compatibility with an existing DEVMAP. The same problem is handled in a third-party ebpf library: - https://github.com/cilium/ebpf/issues/925 - https://github.com/cilium/ebpf/pull/930 Fixes: 0cdbb4b09a06 ("devmap: Allow map lookups from eBPF") Signed-off-by: Yureka Lilian Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250814180113.1245565-3-yuka@yuka.dev Signed-off-by: Sasha Levin

libbpf: Verify that arena map exists when adding arena relocations

2025-08-20T16:30:29+00:00

[ Upstream commit 42be23e8f2dcb100cb9944b2b54b6bf41aff943d ] Fuzzer reported a memory access error in bpf_program__record_reloc() that happens when: - ".addr_space.1" section exists - there is a relocation referencing this section - there are no arena maps defined in BTF. Sanity checks for maps existence are already present in bpf_program__record_reloc(), hence this commit adds another one. [1] https://github.com/libbpf/libbpf/actions/runs/16375110681/job/46272998064 Signed-off-by: Eduard Zingerman Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250718222059.281526-1-eddyz87@gmail.com Signed-off-by: Sasha Levin

libbpf: Fix handling of BPF arena relocations

2025-07-24T06:56:35+00:00

[ Upstream commit 0238c45fbbf8228f52aa4642f0cdc21c570d1dfe ] Initial __arena global variable support implementation in libbpf contains a bug: it remembers struct bpf_map pointer for arena, which is used later on to process relocations. Recording this pointer is problematic because map pointers are not stable during ELF relocation collection phase, as an array of struct bpf_map's can be reallocated, invalidating all the pointers. Libbpf is dealing with similar issues by using a stable internal map index, though for BPF arena map specifically this approach wasn't used due to an oversight. The resulting behavior is non-deterministic issue which depends on exact layout of ELF object file, number of actual maps, etc. We didn't hit this until very recently, when this bug started triggering crash in BPF CI when validating one of sched-ext BPF programs. The fix is rather straightforward: we just follow an established pattern of remembering map index (just like obj->kconfig_map_idx, for example) instead of `struct bpf_map *`, and resolving index to a pointer at the point where map information is necessary. While at it also add debug-level message for arena-related relocation resolution information, which we already have for all other kinds of maps. Fixes: 2e7ba4f8fd1f ("libbpf: Recognize __arena global variables.") Signed-off-by: Andrii Nakryiko Tested-by: Eduard Zingerman Link: https://lore.kernel.org/r/20250718001009.610955-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

libbpf: Fix possible use-after-free for externs

2025-07-06T09:01:40+00:00

[ Upstream commit fa6f092cc0a02d0fcee37e9e8172eda372a03d33 ] The `name` field in `obj->externs` points into the BTF data at initial open time. However, some functions may invalidate this after opening and before loading (e.g. `bpf_map__set_value_size`), which results in pointers into freed memory and undefined behavior. The simplest solution is to simply `strdup` these strings, similar to the `essent_name`, and free them at the same time. In order to test this path, the `global_map_resize` BPF selftest is modified slightly to ensure the presence of an extern, which causes this test to fail prior to the fix. Given there isn't an obvious API or error to test against, I opted to add this to the existing test as an aspect of the resizing feature rather than duplicate the test. Fixes: 9d0a23313b1a ("libbpf: Add capability for resizing datasec maps") Signed-off-by: Adin Scannell Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250625050215.2777374-1-amscanne@meta.com Signed-off-by: Sasha Levin

libbpf: Check bpf_map_skeleton link for NULL

2025-06-27T10:11:31+00:00

[ Upstream commit d0445d7dd3fd9b15af7564c38d7aa3cbc29778ee ] Avoid dereferencing bpf_map_skeleton's link field if it's NULL. If BPF map skeleton is created with the size, that indicates containing link field, but the field was not actually initialized with valid bpf_link pointer, libbpf crashes. This may happen when using libbpf-rs skeleton. Skeleton loading may still progress, but user needs to attach struct_ops map separately. Signed-off-by: Mykyta Yatsenko Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250514113220.219095-1-mykyta.yatsenko5@gmail.com Signed-off-by: Sasha Levin

Use thread-safe function pointer in libbpf_print

2025-06-19T13:31:45+00:00

[ Upstream commit 91dbac4076537b464639953c055c460d2bdfc7ea ] This patch fixes a thread safety bug where libbpf_print uses the global variable storing the print function pointer rather than the local variable that had the print function set via __atomic_load_n. Fixes: f1cb927cdb62 ("libbpf: Ensure print callback usage is thread-safe") Signed-off-by: Jonathan Wiepert Signed-off-by: Andrii Nakryiko Acked-by: Mykyta Yatsenko Link: https://lore.kernel.org/bpf/20250424221457.793068-1-jonathan.wiepert@gmail.com Signed-off-by: Sasha Levin

libbpf: Remove sample_period init in perf_buffer

2025-06-19T13:31:44+00:00

[ Upstream commit 64821d25f05ac468d435e61669ae745ce5a633ea ] It seems that sample_period is not used in perf buffer. Actually, only wakeup_events are meaningful to enable events aggregation for wakeup notification. Remove sample_period setting code to avoid confusion. Fixes: fb84b8224655 ("libbpf: add perf buffer API") Signed-off-by: Tao Chen Signed-off-by: Andrii Nakryiko Acked-by: Jiri Olsa Acked-by: Namhyung Kim Link: https://lore.kernel.org/bpf/20250423163901.2983689-1-chen.dylane@linux.dev Signed-off-by: Sasha Levin

libbpf: Fix event name too long error

2025-06-19T13:31:44+00:00

[ Upstream commit 4dde20b1aa85d69c4281eaac9a7cfa7d2b62ecf0 ] When the binary path is excessively long, the generated probe_name in libbpf exceeds the kernel's MAX_EVENT_NAME_LEN limit (64 bytes). This causes legacy uprobe event attachment to fail with error code -22. The fix reorders the fields to place the unique ID before the name. This ensures that even if truncation occurs via snprintf, the unique ID remains intact, preserving event name uniqueness. Additionally, explicit checks with MAX_EVENT_NAME_LEN are added to enforce length constraints. Before Fix: ./test_progs -t attach_probe/kprobe-long_name ...... libbpf: failed to add legacy kprobe event for 'bpf_testmod_looooooooooooooooooooooooooooooong_name+0x0': -EINVAL libbpf: prog 'handle_kprobe': failed to create kprobe 'bpf_testmod_looooooooooooooooooooooooooooooong_name+0x0' perf event: -EINVAL test_attach_kprobe_long_event_name:FAIL:attach_kprobe_long_event_name unexpected error: -22 test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec #13/11 attach_probe/kprobe-long_name:FAIL #13 attach_probe:FAIL ./test_progs -t attach_probe/uprobe-long_name ...... libbpf: failed to add legacy uprobe event for /root/linux-bpf/bpf-next/tools/testing/selftests/bpf/test_progs:0x13efd9: -EINVAL libbpf: prog 'handle_uprobe': failed to create uprobe '/root/linux-bpf/bpf-next/tools/testing/selftests/bpf/test_progs:0x13efd9' perf event: -EINVAL test_attach_uprobe_long_event_name:FAIL:attach_uprobe_long_event_name unexpected error: -22 #13/10 attach_probe/uprobe-long_name:FAIL #13 attach_probe:FAIL After Fix: ./test_progs -t attach_probe/uprobe-long_name #13/10 attach_probe/uprobe-long_name:OK #13 attach_probe:OK Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED ./test_progs -t attach_probe/kprobe-long_name #13/11 attach_probe/kprobe-long_name:OK #13 attach_probe:OK Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED Fixes: 46ed5fc33db9 ("libbpf: Refactor and simplify legacy kprobe code") Fixes: cc10623c6810 ("libbpf: Add legacy uprobe attaching support") Signed-off-by: Hengqi Chen Signed-off-by: Feng Yang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250417014848.59321-2-yangfeng59949@163.com Signed-off-by: Sasha Levin