linux-stable.git/tools/lib/bpf, branch linux-5.15.y

bpftool: Fix truncated netlink dumps

2026-03-04T12:19:52+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

libbpf: Fix OOB read in btf_dump_get_bitfield_value

2026-03-04T12:19:23+00:00

[ Upstream commit 5714ca8cba5ed736f3733663c446cbee63a10a64 ]

When dumping bitfield data, btf_dump_get_bitfield_value() reads data
based on the underlying type's size (t->size). However, it does not
verify that the provided data buffer (data_sz) is large enough to
contain these bytes.

If btf_dump__dump_type_data() is called with a buffer smaller than
the type's size, this leads to an out-of-bounds read. This was
confirmed by AddressSanitizer in the linked issue.

Fix this by ensuring we do not read past the provided data_sz limit.

Fixes: a1d3cc3c5eca ("libbpf: Avoid use of __int128 in typed dump display")
Reported-by: Harrison Green 
Suggested-by: Alan Maguire 
Signed-off-by: Varun R Mallya 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20260106233527.163487-1-varunrmallya@gmail.com

Closes: https://github.com/libbpf/libbpf/issues/928
Signed-off-by: Sasha Levin

libbpf: Fix dumping big-endian bitfields

2026-03-04T12:19:23+00:00

[ Upstream commit c9e982b879465ca74e3593ce82808aa259265a71 ]

On big-endian arches not only bytes, but also bits are numbered in
reverse order (see e.g. S/390 ELF ABI Supplement, but this is also true
for other big-endian arches as well).

Signed-off-by: Ilya Leoshkevich 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20211013160902.428340-3-iii@linux.ibm.com
Stable-dep-of: 5714ca8cba5e ("libbpf: Fix OOB read in btf_dump_get_bitfield_value")
Signed-off-by: Sasha Levin

libbpf: Fix invalid return address register in s390

2025-12-06T21:09:37+00:00

commit 7244eb669397f309c3d014264823cdc9cb3f8e6b upstream.

There is currently an invalid register mapping in the s390 return
address register. As the manual[1] states, the return address can be
found at r14. In bpf_tracing.h, the s390 registers were named
gprs(general purpose registers). This commit fixes the problem by
correcting the mistyped mapping.

[1]: https://uclibc.org/docs/psABI-s390x.pdf#page=14

Fixes: 3cc31d794097 ("libbpf: Normalize PT_REGS_xxx() macro definitions")
Signed-off-by: Daniel T. Lee 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20221224071527.2292-7-danieltimlee@gmail.com
Signed-off-by: Greg Kroah-Hartman

libbpf, riscv: Use a0 for RC register

2025-12-06T21:09:37+00:00

commit 935dc35c75318fa213d26808ad8bb130fb0b486e upstream.

According to the RISC-V calling convention register usage here [0], a0
is used as return value register, so rename it to make it consistent
with the spec.

  [0] section 18.2, table 18.2
      https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf

Fixes: 589fed479ba1 ("riscv, libbpf: Add RISC-V (RV64) support to bpf_tracing.h")
Signed-off-by: Yixun Lan 
Signed-off-by: Daniel Borkmann 
Acked-by: Björn Töpel 
Acked-by: Amjad OULED-AMEUR 
Link: https://lore.kernel.org/bpf/20220706140204.47926-1-dlan@gentoo.org
Signed-off-by: Greg Kroah-Hartman

libbpf: Fix riscv register names

2025-12-06T21:09:37+00:00

commit 5c101153bfd67387ba159b7864176217a40757da upstream.

riscv registers are accessed via struct user_regs_struct, not struct
pt_regs. The program counter member in this struct is called pc, not
epc. The frame pointer is called s0, not fp.

Fixes: 3cc31d794097 ("libbpf: Normalize PT_REGS_xxx() macro definitions")
Signed-off-by: Ilya Leoshkevich 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20220209021745.2215452-6-iii@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman

libbpf: Fix powerpc's stack register definition in bpf_tracing.h

2025-12-06T21:09:14+00:00

[ Upstream commit 7221b9caf84b3294688228a19273d74ea19a2ee4 ]

retsnoop's build on powerpc (ppc64le) architecture ([0]) failed due to
wrong definition of PT_REGS_SP() macro. Looking at powerpc's
implementation of stack unwinding in perf_callchain_user_64() clearly
shows that stack pointer register is gpr[1].

Fix libbpf's definition of __PT_SP_REG for powerpc to fix all this.

  [0] https://kojipkgs.fedoraproject.org/work/tasks/1544/137921544/build.log

Fixes: 138d6153a139 ("samples/bpf: Enable powerpc support")
Signed-off-by: Andrii Nakryiko 
Reviewed-by: Naveen N Rao (AMD) 
Link: https://lore.kernel.org/r/20251020203643.989467-1-andrii@kernel.org
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin

libbpf: Normalize PT_REGS_xxx() macro definitions

2025-12-06T21:09:14+00:00

[ Upstream commit 3cc31d794097a0de5ac619d4a20b1975139e6b05 ]

Refactor PT_REGS macros definitions in  bpf_tracing.h to avoid excessive
duplication. We currently have classic PT_REGS_xxx() and CO-RE-enabled
PT_REGS_xxx_CORE(). We are about to add also _SYSCALL variants, which
would require excessive copying of all the per-architecture definitions.

Instead, separate architecture-specific field/register names from the
final macro that utilize them. That way for upcoming _SYSCALL variants
we'll be able to just define x86_64 exception and otherwise have one
common set of _SYSCALL macro definitions common for all architectures.

Signed-off-by: Andrii Nakryiko 
Signed-off-by: Alexei Starovoitov 
Tested-by: Ilya Leoshkevich 
Acked-by: Yonghong Song 
Acked-by: Ilya Leoshkevich 
Link: https://lore.kernel.org/bpf/20211222213924.1869758-1-andrii@kernel.org
Stable-dep-of: 7221b9caf84b ("libbpf: Fix powerpc's stack register definition in bpf_tracing.h")
Signed-off-by: Sasha Levin

riscv, libbpf: Add RISC-V (RV64) support to bpf_tracing.h

2025-12-06T21:09:14+00:00

[ Upstream commit 589fed479ba1e93f94d9772aa6162cd81f7e491c ]

Add macros for 64-bit RISC-V PT_REGS to bpf_tracing.h.

Signed-off-by: Björn Töpel 
Signed-off-by: Daniel Borkmann 
Link: https://lore.kernel.org/bpf/20211028161057.520552-4-bjorn@kernel.org
Stable-dep-of: 7221b9caf84b ("libbpf: Fix powerpc's stack register definition in bpf_tracing.h")
Signed-off-by: Sasha Levin

libbpf: Fix reuse of DEVMAP

2025-10-19T14:21:29+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