I was about to sent my fix, just to realize I got beaten by half and
hour+ even with my 6 hour timezone advantage :)
On Thu, Apr 10, 2025 at 09:34:07AM +0200, Viktor Malik wrote:
> As reported by CVE-2025-29481 (link below), it is possible to corrupt a
> BPF ELF file such that arbitrary BPF instructions are loaded by libbpf.
> This can be done by setting a symbol (BPF program) section offset to a
> sufficiently large (unsigned) number such <section_start+symbol_offset>
> overflows and points before the section.
>
> Consider the situation below where:
> - prog_start = sec_start + symbol_offset <-- size_t overflow here
> - prog_end = prog_start + prog_size
>
> prog_start sec_start prog_end sec_end
> | | | |
> v v v v
> .....................|################################|............
>
> Currently, libbpf only checks that prog_end is within the section
> bounds. Add a check that prog_start is also within the bounds to avoid
> the potential buffer overflow.
I would add
Reported-by: lmarch2 <2524158037@xxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
Fixes: 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions")
There used to be a 'while (sec_off < sec_sz)' check that would prevent
this issue, but with commit 6245947c1b3c that was removed.
---
Nit: it would be nice if some concrete values from the reproducer is
included
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
...
[ 2] uretprobe.multi.snter_write PROGBITS 0000000000000000 000040 000068 00 AX 0 0 8
Symbol table '.symtab' contains 8 entries:
Num: Value Size Type Bind Vis Ndx Name
...
6: ffffffffffffffb8 104 FUNC GLOBAL DEFAULT 2 handle_tp
As well as AddressSanitizer output:
libbpf: loading object from crash-04573b0232eeaed1b2cd9f10e4fadc122c560e7a
libbpf: elf: section(2) uretprobe.multi.snter_write, size 104, link 0, flags 6, type=1
libbpf: sec 'uretprobe.multi.snter_write': found program 'handle_tp' at insn offset 0 (0 bytes), code size 13 insns (104 bytes)
libbpf: sec 'uretprobe.multi.snter_write': found program 'handle_tp' at insn offset 2305843009213693943 (18446744073709551544 bytes), code size 13 insns (104 bytes)
=================================================================
==169293==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7c1fc6be0000 at pc 0x7f6fc831f877 bp 0x7ffc89800a30 sp 0x7ffc898001f0
READ of size 104 at 0x7c1fc6be0000 thread T0
#0 0x7f6fc831f876 in memcpy (/lib64/libasan.so.8+0x11f876) (BuildId: 7a83eb8b5639d83795773bfac12481d6f3243469)
#1 0x00000040fcbf in bpf_object__init_prog ./tools/lib/bpf/libbpf.c:856
#2 0x00000040fcbf in bpf_object__add_programs ./tools/lib/bpf/libbpf.c:928
#3 0x00000040fcbf in bpf_object__elf_collect ./tools/lib/bpf/libbpf.c:3930
#4 0x00000040fcbf in bpf_object_open ./tools/lib/bpf/libbpf.c:8067
#5 0x000000411b83 in bpf_object__open_file ./tools/lib/bpf/libbpf.c:8090
#6 0x000000403966 in main (../poc/libbpf/poc+0x403966) (BuildId: 9d80b3f3edc46b2a3684427aad5fe2bcda2b5ea4)
...
> Link: https://github.com/lmarch2/poc/blob/main/libbpf/libbpf.md
> Link: https://www.cve.org/CVERecord?id=CVE-2025-29481
> Signed-off-by: Viktor Malik <vmalik@xxxxxxxxxx>
Code-wise LGTM
Reviewed-by: Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx>
