kernel/git/stable/linux.git/tools/bpf, branch linux-6.10.y

bpftool: Fix undefined behavior in qsort(NULL, 0, ...)

2024-10-10T10:00:40+00:00

[ Upstream commit f04e2ad394e2755d0bb2d858ecb5598718bf00d5 ] When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: "Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined." To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer. Signed-off-by: Kuan-Wei Chiu Signed-off-by: Andrii Nakryiko Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20240910150207.3179306-1-visitorckw@gmail.com Signed-off-by: Sasha Levin

bpftool: Fix undefined behavior caused by shifting into the sign bit

2024-10-10T10:00:40+00:00

[ Upstream commit 4cdc0e4ce5e893bc92255f5f734d983012f2bc2e ] Replace shifts of '1' with '1U' in bitwise operations within __show_dev_tc_bpf() to prevent undefined behavior caused by shifting into the sign bit of a signed integer. By using '1U', the operations are explicitly performed on unsigned integers, avoiding potential integer overflow or sign-related issues. Signed-off-by: Kuan-Wei Chiu Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20240908140009.3149781-1-visitorckw@gmail.com Signed-off-by: Sasha Levin

tools/runqslower: Fix LDFLAGS and add LDLIBS support

2024-10-04T14:32:50+00:00

[ Upstream commit f86601c3661946721e8f260bdd812b759854ac22 ] Actually use previously defined LDFLAGS during build and add support for LDLIBS to link extra standalone libraries e.g. 'argp' which is not provided by musl libc. Fixes: 585bf4640ebe ("tools: runqslower: Add EXTRA_CFLAGS and EXTRA_LDFLAGS support") Signed-off-by: Tony Ambardar Signed-off-by: Andrii Nakryiko Acked-by: Ilya Leoshkevich Link: https://lore.kernel.org/bpf/20240723003045.2273499-1-tony.ambardar@gmail.com Signed-off-by: Sasha Levin

tools/resolve_btfids: Fix comparison of distinct pointer types warning in resolve_btfids

2024-08-03T07:01:02+00:00

[ Upstream commit 13c9b702e6cb8e406d5fa6b2dca422fa42d2f13e ] Add a type cast for set8->pairs to fix below compile warning: main.c: In function 'sets_patch': main.c:699:50: warning: comparison of distinct pointer types lacks a cast 699 | BUILD_BUG_ON(set8->pairs != &set8->pairs[0].id); | ^~ Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h") Signed-off-by: Liwei Song Signed-off-by: Daniel Borkmann Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20240722083305.4009723-1-liwei.song.lsong@gmail.com Signed-off-by: Sasha Levin

bpftool: Mount bpffs when pinmaps path not under the bpffs

2024-08-03T06:59:42+00:00

[ Upstream commit da5f8fd1f0d393d5eaaba9ad8c22d1c26bb2bf9b ] As Quentin said [0], BPF map pinning will fail if the pinmaps path is not under the bpffs, like: libbpf: specified path /home/ubuntu/test/sock_ops_map is not on BPF FS Error: failed to pin all maps [0] https://github.com/libbpf/bpftool/issues/146 Fixes: 3767a94b3253 ("bpftool: add pinmaps argument to the load/loadall") Signed-off-by: Tao Chen Signed-off-by: Daniel Borkmann Tested-by: Quentin Monnet Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20240702131150.15622-1-chen.dylane@gmail.com Signed-off-by: Sasha Levin

bpftool: Un-const bpf_func_info to fix it for llvm 17 and newer

2024-08-03T06:59:32+00:00

[ Upstream commit f4aba3471cfb9ccf69b476463f19b4c50fef6b14 ] LLVM 17 started treating const structs as constants: * https://github.com/llvm/llvm-project/commit/0b2d5b967d98 Combined with pointer laundering via ptr_to_u64, which takes a const ptr, but in reality treats the underlying memory as mutable, this makes clang always pass zero to btf__type_by_id, which breaks full name resolution. Disassembly before (LLVM 16) and after (LLVM 17): - 8b 75 cc mov -0x34(%rbp),%esi - e8 47 8d 02 00 call 3f5b0 + 31 f6 xor %esi,%esi + e8 a9 8c 02 00 call 3f510 It's a bigger project to fix this properly (and a question whether LLVM itself should detect this), but for right now let's just fix bpftool. For more information, see this thread in bpf mailing list: * https://lore.kernel.org/bpf/CABWYdi0ymezpYsQsPv7qzpx2fWuTkoD1-wG1eT-9x-TSREFrQg@mail.gmail.com/T/ Fixes: b662000aff84 ("bpftool: Adding support for BTF program names") Signed-off-by: Ivan Babrou Signed-off-by: Andrii Nakryiko Acked-by: Nick Desaulniers Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20240520225149.5517-1-ivan@cloudflare.com Signed-off-by: Sasha Levin

bpf: Fix potential integer overflow in resolve_btfids

2024-05-24T15:12:12+00:00

err is a 32-bit integer, but elf_update returns an off_t, which is 64-bit at least on 64-bit platforms. If symbols_patch is called on a binary between 2-4GB in size, the result will be negative when cast to a 32-bit integer, which the code assumes means an error occurred. This can wrongly trigger build failures when building very large kernel images. Fixes: fbbb68de80a4 ("bpf: Add resolve_btfids tool to resolve BTF IDs in ELF object") Signed-off-by: Friedrich Vock Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20240514070931.199694-1-friedrich.vock@gmx.de

bpftool, selftests/hid/bpf: Fix 29 clang warnings

2024-05-06T21:39:36+00:00

When building either tools/bpf/bpftool, or tools/testing/selftests/hid, (the same Makefile is used for these), clang generates many instances of the following: "clang: warning: -lLLVM-17: 'linker' input unused" Quentin points out that the LLVM version is only required in $(LIBS), not in $(CFLAGS), so the fix is to remove it from CFLAGS. Suggested-by: Quentin Monnet Signed-off-by: John Hubbard Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20240505230054.13813-1-jhubbard@nvidia.com

bpftool: Address minor issues in bash completion

2024-04-16T15:58:25+00:00

This commit contains a series of clean-ups and fixes for bpftool's bash completion file: - Make sure all local variables are declared as such. - Make sure variables are initialised before being read. - Update ELF section ("maps" -> ".maps") for looking up map names in object files. - Fix call to _init_completion. - Move definition for MAP_TYPE and PROG_TYPE higher up in the scope to avoid defining them multiple times, reuse MAP_TYPE where relevant. - Simplify completion for "duration" keyword in "bpftool prog profile". - Fix completion for "bpftool struct_ops register" and "bpftool link (pin|detach)" where we would repeatedly suggest file names instead of suggesting just one name. - Fix completion for "bpftool iter pin ... map MAP" to account for the "map" keyword. - Add missing "detach" suggestion for "bpftool link". Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20240413011427.14402-3-qmo@kernel.org

bpftool: Update documentation where progs/maps can be passed by name

2024-04-16T15:58:25+00:00

When using references to BPF programs, bpftool supports passing programs by name on the command line. The manual pages for "bpftool prog" and "bpftool map" (for prog_array updates) mention it, but we have a few additional subcommands that support referencing programs by name but do not mention it in their documentation. Let's update the pages for subcommands "btf", "cgroup", and "net". Similarly, we can reference maps by name when passing them to "bpftool prog load", so we update the page for "bpftool prog" as well. Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20240413011427.14402-2-qmo@kernel.org