kernel/linux.git/tools/bpf/bpftool/cgroup.c, 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: 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

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

bpftool: Query only cgroup-related attach types

2024-06-11T18:39:09+00:00

When CONFIG_NETKIT=y, bpftool-cgroup shows error even if the cgroup's path is correct: $ bpftool cgroup tree /sys/fs/cgroup CgroupPath ID AttachType AttachFlags Name Error: can't query bpf programs attached to /sys/fs/cgroup: No such device or address >From strace and kernel tracing, I found netkit returned ENXIO and this command failed. I think this AttachType(BPF_NETKIT_PRIMARY) is not relevant to cgroup. bpftool-cgroup should query just only cgroup-related attach types. v2->v3: - removed an unnecessary check v1->v2: - used an array of cgroup attach types Signed-off-by: Kenta Tada Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/r/20240607111704.6716-1-tadakentaso@gmail.com Signed-off-by: Alexei Starovoitov

bpftool: Add support for cgroup unix socket address hooks

2023-10-12T00:27:55+00:00

Add the necessary plumbing to hook up the new cgroup unix sockaddr hooks into bpftool. Signed-off-by: Daan De Meyer Acked-by: Quentin Monnet Link: https://lore.kernel.org/r/20231011185113.140426-7-daan.j.demeyer@gmail.com Signed-off-by: Martin KaFai Lau

bpftool: Use bpf_{btf,link,map,prog}_get_info_by_fd()

2023-02-16T23:32:45+00:00

Use the new type-safe wrappers around bpf_obj_get_info_by_fd(). Split the bpf_obj_get_info_by_fd() call in build_btf_type_table() in two, since knowing the type helps with the Memory Sanitizer. Improve map_parse_fd_and_info() type safety by using struct bpf_map_info * instead of void * for info. Signed-off-by: Ilya Leoshkevich Signed-off-by: Andrii Nakryiko Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20230214231221.249277-4-iii@linux.ibm.com

bpftool: Fix wrong cgroup attach flags being assigned to effective progs

2022-09-21T17:57:12+00:00

When root-cgroup attach multi progs and sub-cgroup attach a override prog, bpftool will display incorrectly for the attach flags of the sub-cgroup’s effective progs: $ bpftool cgroup tree /sys/fs/cgroup effective CgroupPath ID AttachType AttachFlags Name /sys/fs/cgroup 6 cgroup_sysctl multi sysctl_tcp_mem 13 cgroup_sysctl multi sysctl_tcp_mem /sys/fs/cgroup/cg1 20 cgroup_sysctl override sysctl_tcp_mem 6 cgroup_sysctl override sysctl_tcp_mem <- wrong 13 cgroup_sysctl override sysctl_tcp_mem <- wrong /sys/fs/cgroup/cg1/cg2 20 cgroup_sysctl sysctl_tcp_mem 6 cgroup_sysctl sysctl_tcp_mem 13 cgroup_sysctl sysctl_tcp_mem Attach flags is only valid for attached progs of this layer cgroup, but not for effective progs. For querying with EFFECTIVE flags, exporting attach flags does not make sense. So let's remove the AttachFlags field and the associated logic. After this patch, the above effective cgroup tree will show as bellow: $ bpftool cgroup tree /sys/fs/cgroup effective CgroupPath ID AttachType Name /sys/fs/cgroup 6 cgroup_sysctl sysctl_tcp_mem 13 cgroup_sysctl sysctl_tcp_mem /sys/fs/cgroup/cg1 20 cgroup_sysctl sysctl_tcp_mem 6 cgroup_sysctl sysctl_tcp_mem 13 cgroup_sysctl sysctl_tcp_mem /sys/fs/cgroup/cg1/cg2 20 cgroup_sysctl sysctl_tcp_mem 6 cgroup_sysctl sysctl_tcp_mem 13 cgroup_sysctl sysctl_tcp_mem Fixes: b79c9fc9551b ("bpf: implement BPF_PROG_QUERY for BPF_LSM_CGROUP") Fixes: a98bf57391a2 ("tools: bpftool: add support for reporting the effective cgroup progs") Signed-off-by: Pu Lehui Link: https://lore.kernel.org/r/20220921104604.2340580-3-pulehui@huaweicloud.com Signed-off-by: Martin KaFai Lau

bpftool: implement cgroup tree for BPF_LSM_CGROUP

2022-06-29T20:21:52+00:00

$ bpftool --nomount prog loadall $KDIR/tools/testing/selftests/bpf/lsm_cgroup.o /sys/fs/bpf/x $ bpftool cgroup attach /sys/fs/cgroup lsm_cgroup pinned /sys/fs/bpf/x/socket_alloc $ bpftool cgroup attach /sys/fs/cgroup lsm_cgroup pinned /sys/fs/bpf/x/socket_bind $ bpftool cgroup attach /sys/fs/cgroup lsm_cgroup pinned /sys/fs/bpf/x/socket_clone $ bpftool cgroup attach /sys/fs/cgroup lsm_cgroup pinned /sys/fs/bpf/x/socket_post_create $ bpftool cgroup tree CgroupPath ID AttachType AttachFlags Name /sys/fs/cgroup 6 lsm_cgroup socket_post_create bpf_lsm_socket_post_create 8 lsm_cgroup socket_bind bpf_lsm_socket_bind 10 lsm_cgroup socket_alloc bpf_lsm_sk_alloc_security 11 lsm_cgroup socket_clone bpf_lsm_inet_csk_clone $ bpftool cgroup detach /sys/fs/cgroup lsm_cgroup pinned /sys/fs/bpf/x/socket_post_create $ bpftool cgroup tree CgroupPath ID AttachType AttachFlags Name /sys/fs/cgroup 8 lsm_cgroup socket_bind bpf_lsm_socket_bind 10 lsm_cgroup socket_alloc bpf_lsm_sk_alloc_security 11 lsm_cgroup socket_clone bpf_lsm_inet_csk_clone Reviewed-by: Quentin Monnet Acked-by: Martin KaFai Lau Signed-off-by: Stanislav Fomichev Link: https://lore.kernel.org/r/20220628174314.1216643-11-sdf@google.com Signed-off-by: Alexei Starovoitov

bpftool: Use libbpf_bpf_attach_type_str

2022-06-02T23:26:30+00:00

This change switches bpftool over to using the recently introduced libbpf_bpf_attach_type_str function instead of maintaining its own string representation for the bpf_attach_type enum. Note that contrary to other enum types, the variant names that bpftool maps bpf_attach_type to do not adhere a simple to follow rule. With bpf_prog_type, for example, the textual representation can easily be inferred by stripping the BPF_PROG_TYPE_ prefix and lowercasing the remaining string. bpf_attach_type violates this rule for various variants. We decided to fix up this deficiency with this change, meaning that bpftool uses the same textual representations as libbpf. Supporting tests, completion scripts, and man pages have been adjusted accordingly. However, we did add support for accepting (the now undocumented) original attach type names when they are provided by users. For the test (test_bpftool_synctypes.py), I have removed the enum representation checks, because we no longer mirror the various enum variant names in bpftool source code. For the man page, help text, and completion script checks we are now using enum definitions from uapi/linux/bpf.h as the source of truth directly. Signed-off-by: Daniel Müller Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20220523230428.3077108-10-deso@posteo.net

bpftool: Adding support for BTF program names

2022-01-19T18:04:41+00:00

`bpftool prog list` and other bpftool subcommands that show BPF program names currently get them from bpf_prog_info.name. That field is limited to 16 (BPF_OBJ_NAME_LEN) chars which leads to truncated names since many progs have much longer names. The idea of this change is to improve all bpftool commands that output prog name so that bpftool uses info from BTF to print program names if available. It tries bpf_prog_info.name first and fall back to btf only if the name is suspected to be truncated (has 15 chars length). Right now `bpftool p show id ` returns capped prog name : kprobe name example_cap_cap tag 712e... ... With this change it would return : kprobe name example_cap_capable tag 712e... ... Note, other commands that print prog names (e.g. "bpftool cgroup tree") are also addressed in this change. Signed-off-by: Raman Shukhau Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220119100255.1068997-1-ramasha@fb.com