kernel/linux.git/tools/bpf, branch v6.12.98

bpftool: Fix vmlinux BTF leak in cgroup commands

2026-07-24T14:11:13+00:00

[ Upstream commit bda6a7308ef8e79cfbb7d09e48e1c7ffaa522269 ] bpftool cgroup show and tree call libbpf_find_kernel_btf() to resolve attach_btf names, but never release the returned BTF object. For cgroup tree, do_show_tree_fn() is called once for each cgroup visited by nftw(). When more than one cgroup has attached programs, each callback overwrites btf_vmlinux with a new object and loses the previous allocation. Load vmlinux BTF only once during a tree walk and release it when cgroup show or tree completes. Reset btf_vmlinux_id at the same time so batch mode starts with clean state. Fixes: 596f5fb2ea2a ("bpftool: implement cgroup tree for BPF_LSM_CGROUP") Signed-off-by: Yichong Chen Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/r/24357C69B4405079+20260617090117.280222-1-chenyichong@uniontech.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

bpftool: Use libbpf error code for flow dissector query

2026-07-24T14:10:53+00:00

[ Upstream commit 8a7f2bff2165e53595d1e91c160b340f978c0ab7 ] bpf_prog_query() returns a negative errno on failure. query_flow_dissector() currently closes the namespace fd and then reads errno to decide whether -EINVAL means that the running kernel does not support flow dissector queries. That errno check controls behavior, not just diagnostics: -EINVAL is handled as a non-fatal old-kernel case, while any other error makes bpftool net fail. The namespace fd is opened read-only, so close() is not expected to commonly fail in normal use. Still, the BPF_PROG_QUERY error is already available in err, and reading errno after an intervening close() is fragile. If close() does change errno, the compatibility branch may be based on close()'s error instead of the BPF_PROG_QUERY result. This was reproduced with an LD_PRELOAD fault injector that forced BPF_PROG_QUERY for BPF_FLOW_DISSECTOR to fail with EINVAL and then forced close() on the netns fd to fail with EIO. The unpatched bpftool reported "can't query prog: Input/output error". With this change, the same injected failure is handled as the intended non-fatal EINVAL compatibility case. Use the libbpf-returned error code instead. Keep the existing errno reset in the non-fatal path to preserve batch mode behavior. The success path is unchanged. Fixes: 7f0c57fec80f ("bpftool: show flow_dissector attachment status") Signed-off-by: Woojin Ji Signed-off-by: Andrii Nakryiko Acked-by: Leon Hwang Acked-by: Yonghong Song Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20260603003339.33791-1-random6.xyz@gmail.com Assisted-by: ChatGPT:gpt-5.5 Signed-off-by: Sasha Levin

bpftool: Fix typo in struct_ops map FD generation for light skeleton

2026-07-24T14:10:51+00:00

[ Upstream commit be4c6c7bc42952b71188894933946b410deadcfe ] When generating light skeletons for BPF programs containing struct_ops maps, bpftool incorrectly outputs a stray literal 't' instead of a tab character for the map file descriptor member in the links structure. This causes a compilation error when the generated light skeleton is used. Correct the format string by replacing 't' with '\t'. Fixes: 08ac454e258e ("libbpf: Auto-attach struct_ops BPF maps in BPF skeleton") Signed-off-by: Siddharth Nayyar Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20260520-struct_ops_gen_typo_fix-v1-1-4dee3771da46@google.com Signed-off-by: Sasha Levin

bpftool: Fix truncated netlink dumps

2026-03-04T12:20:38+00:00

[ Upstream commit 3b39d73cc3379360a33eb583b17f21fe55e1288e ] Netlink requires that the recv buffer used during dumps is at least min(PAGE_SIZE, 8k) (see the man page). Otherwise the messages will get truncated. Make sure bpftool follows this requirement, avoid missing information on systems with large pages. Acked-by: Quentin Monnet Fixes: 7084566a236f ("tools/bpftool: Remove libbpf_internal.h usage in bpftool") Signed-off-by: Jakub Kicinski Link: https://lore.kernel.org/r/20260217194150.734701-1-kuba@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

bpftool: Fix -Wuninitialized-const-pointer warnings with clang >= 21

2025-11-13T20:34:06+00:00

[ Upstream commit 5612ea8b554375d45c14cbb0f8ea93ec5d172891 ] This fixes the build with -Werror -Wall. btf_dumper.c:71:31: error: variable 'finfo' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 71 | info.func_info = ptr_to_u64(&finfo); | ^~~~~ prog.c:2294:31: error: variable 'func_info' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 2294 | info.func_info = ptr_to_u64(&func_info); | v2: - Initialize instead of using memset. Signed-off-by: Tom Stellard Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20250917183847.318163-1-tstellar@redhat.com Signed-off-by: Sasha Levin

bpftool: Fix JSON writer resource leak in version command

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

[ Upstream commit 85cd83fed8267cde0dd1cea719808aad95ae4de7 ] When using `bpftool --version -j/-p`, the JSON writer object created in do_version() was not properly destroyed after use. This caused a memory leak each time the version command was executed with JSON output. Fix: 004b45c0e51a (tools: bpftool: provide JSON output for all possible commands) Suggested-by: Quentin Monnet Signed-off-by: Yuan Chen Signed-off-by: Andrii Nakryiko Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20250617132442.9998-1-chenyuan_fl@163.com Signed-off-by: Sasha Levin

bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure

2025-08-15T10:13:40+00:00

[ Upstream commit 99fe8af069a9fa5b09140518b1364e35713a642e ] In function dump_xx_nlmsg(), when realloc() fails to allocate memory, the original pointer to the buffer is overwritten with NULL. This causes a memory leak because the previously allocated buffer becomes unreachable without being freed. Fixes: 7900efc19214 ("tools/bpf: bpftool: improve output format for bpftool net") Signed-off-by: Yuan Chen Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/r/20250620012133.14819-1-chenyuan_fl@163.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

bpftool: Fix cgroup command to only show cgroup bpf programs

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

commit b69d4413aa1961930fbf9ffad8376d577378daf9 upstream. The netkit program is not a cgroup bpf program and should not be shown in the output of the "bpftool cgroup show" command. However, if the netkit device happens to have ifindex 3, the "bpftool cgroup show" command will output the netkit bpf program as well: > ip -d link show dev nk1 3: nk1@if2: ... link/ether ... netkit mode ... > bpftool net show tc: nk1(3) netkit/peer tw_ns_nk2phy prog_id 469447 > bpftool cgroup show /sys/fs/cgroup/... ID AttachType AttachFlags Name ... ... ... 469447 netkit_peer tw_ns_nk2phy The reason is that the target_fd (which is the cgroup_fd here) and the target_ifindex are in a union in the uapi/linux/bpf.h. The bpftool iterates all values in "enum bpf_attach_type" which includes non cgroup attach types like netkit. The cgroup_fd is usually 3 here, so the bug is triggered when the netkit ifindex just happens to be 3 as well. The bpftool's cgroup.c already has a list of cgroup-only attach type defined in "cgroup_attach_types[]". This patch fixes it by iterating over "cgroup_attach_types[]" instead of "__MAX_BPF_ATTACH_TYPE". Cc: Quentin Monnet Reported-by: Takshak Chahande Signed-off-by: Martin KaFai Lau Acked-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/r/20250507203232.1420762-1-martin.lau@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman

tools/resolve_btfids: Fix build when cross compiling kernel with clang.

2025-06-19T13:32:33+00:00

commit a298bbab903e3fb4cbe16d36d6195e68fad1b776 upstream. When cross compiling the kernel with clang, we need to override CLANG_CROSS_FLAGS when preparing the step libraries. Prior to commit d1d096312176 ("tools: fix annoying "mkdir -p ..." logs when building tools in parallel"), MAKEFLAGS would have been set to a value that wouldn't set a value for CLANG_CROSS_FLAGS, hiding the fact that we weren't properly overriding it. Fixes: 56a2df7615fa ("tools/resolve_btfids: Compile resolve_btfids as host program") Signed-off-by: Suleiman Souhlal Signed-off-by: Andrii Nakryiko Acked-by: Jiri Olsa Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20250606074538.1608546-1-suleiman@google.com Signed-off-by: Greg Kroah-Hartman

bpftool: Fix regression of "bpftool cgroup tree" EINVAL on older kernels

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

[ Upstream commit 43745d11bfd9683abdf08ad7a5cc403d6a9ffd15 ] If cgroup_has_attached_progs queries an attach type not supported by the running kernel, due to the kernel being older than the bpftool build, it would encounter an -EINVAL from BPF_PROG_QUERY syscall. Prior to commit 98b303c9bf05 ("bpftool: Query only cgroup-related attach types"), this EINVAL would be ignored by the function, allowing the function to only consider supported attach types. The commit changed so that, instead of querying all attach types, only attach types from the array `cgroup_attach_types` is queried. The assumption is that because these are only cgroup attach types, they should all be supported. Unfortunately this assumption may be false when the kernel is older than the bpftool build, where the attach types queried by bpftool is not yet implemented in the kernel. This would result in errors such as: $ bpftool cgroup tree CgroupPath ID AttachType AttachFlags Name Error: can't query bpf programs attached to /sys/fs/cgroup: Invalid argument This patch restores the logic of ignoring EINVAL from prior to that patch. Fixes: 98b303c9bf05 ("bpftool: Query only cgroup-related attach types") Reported-by: Sagarika Sharma Reported-by: Minh-Anh Nguyen Signed-off-by: YiFei Zhu Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20250428211536.1651456-1-zhuyifei@google.com Signed-off-by: Sasha Levin