The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Henrik Grimler <henrik@grimler.se>
Cc: Aelin Reidel <aelin@mainlining.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	Jiri Olsa <jolsa@kernel.org>,
	Emil Tsalapatis <emil@etsalapatis.com>,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] resolve_btfids: preserve tag and parameter names when processing implicit args
Date: Tue, 7 Jul 2026 12:44:47 -0700	[thread overview]
Message-ID: <bec46089-abc2-418e-9b27-34dd9f6d1dde@linux.dev> (raw)
In-Reply-To: <20260707075500.GA10854@localhost>

On 7/7/26 12:55 AM, Henrik Grimler wrote:
> Hi Ihor,
> 
> On Thu, Jun 25, 2026 at 10:26:27PM -0700, Ihor Solodrai wrote:
>> [...]
>>
>> However you have a stable reproducer, so your strdup() change probably
>> covers a real UAF bug somewhere else (in libbpf?).
>>
>> Let's track this down before coming up with a fix.
>>
>> What version/commit of libbpf are you using in your kernel tree?
> 
> I use the same build environment as Aelin and get the same issue with
> resolve_btfids from linux v7.1.1. System libbpf is at v1.7.0 [1] (but
> I guess this is not relevant? resolve_btfids is not linked against
> it).
> 
>> You could build resolve_btfids with ASAN, or run it with valgrind.
> 
> Valgrind reports some invalid reads, see log here:
> https://grimler.se/files/valgrind-resolve-btfids.txt
> 
> and if run under gdb I get:
> 
> ```
> $ gdb -ex r --args tools/bpf/resolve_btfids/resolve_btfids --fatal_warnings --verbose --btf .tmp_vmlinux1.BTF.1 .tmp_vmlinux1
> [ ... ]
> found kfunc tcp_reno_ssthresh in BTF_ID_FLAGS bpf_tcp_ca_check_kfunc_ids
> found kfunc tcp_reno_undo_cwnd in BTF_ID_FLAGS bpf_tcp_ca_check_kfunc_ids
> found kfunc tcp_slow_start in BTF_ID_FLAGS bpf_tcp_ca_check_kfunc_ids
> resolve_btfids: function bpf_list_push_back_impl already exists in BTF
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7f7aaa0 in memcpy (dest=0x7fffebb05a93, src=<optimized out>, n=5) at src/string/memcpy.c:23
> warning: 23     src/string/memcpy.c: No such file or directory
> (gdb) bt
> #0  0x00007ffff7f7aaa0 in memcpy (dest=0x7fffebb05a93, src=<optimized out>, n=5) at src/string/memcpy.c:23
> #1  0x000055555559865b in _ZL6memcpyPvU17pass_object_size0PKvU17pass_object_size0m (__od=0x7fffeb115c71, __os=0x7fffeb115c71, __n=5) at /usr/include/fortify/string.h:57
> #2  strset__add_str (set=0x7fffebb85fd0, s=s@entry=0x7fffeb115c71 <error: Cannot access memory at address 0x7fffeb115c71>) at strset.c:162
> #3  0x0000555555587b2c in btf__add_str (btf=btf@entry=0x7fffebb860a0, s=0x7fffeb115c71 <error: Cannot access memory at address 0x7fffeb115c71>) at btf.c:2109
> #4  0x00005555555898b1 in btf__add_func_param (btf=0x7fffebb860a0, name=0x7fffeb115c71 <error: Cannot access memory at address 0x7fffeb115c71>, type_id=11011) at btf.c:3108
> #5  0x000055555555de50 in process_kfunc_with_implicit_args (ctx=0x7fffffffd7d0, kfunc=0x7fffebb739a0) at main.c:1196
> #6  0x000055555555cc02 in btf2btf (obj=0x7fffffffd868) at main.c:1229
> #7  0x000055555555b869 in main (argc=1, argv=0x7fffffffec08) at main.c:1535
> ```
> 
>> If you can share a reproducer that's easy to run, that would be
>> great too.
> 
> I have uploaded .tmp_vmlinux1 and .tmp_vmlinux1.BTF.1 files (for an
> ARM kernel) that reproduce the issue here:
> 
> https://grimler.se/files/tmp_vmlinux1
> https://grimler.se/files/tmp_vmlinux1.BTF.1

Hi Henrik,

Thanks for the reproducer and the logs, very helpful.
The crash you hit is a real UAF that was recently fixed in libbpf:

    b23705e6afb6 ("libbpf: Fix UAF in strset__add_str()") [1]

strset__add_str() reallocs its buffer, then copies from a string that
may point into that same buffer (what btf__name_by_offset() returns)
dangling after the realloc.

I ran unpatched resolve_btfids under valgrind on your binaries,
toggling only b23705e6afb6.

Reverting b23705e6afb6:

    Invalid read of size 1
       at memmove
       by strset__add_str (strset.c:162)
       by btf__add_str (btf.c:2109)
       by btf__add_func_param (btf.c:3118)
       by process_kfunc_with_implicit_args (main.c:1196)
       by btf2btf (main.c:1229)
       by main (main.c:1535)
     Address 0x11dfb901 is 22,721 bytes inside a block of size 1,787,619 free'd
       at realloc
       by libbpf_add_mem (btf.c:224)
       by strset_add_str_mem (strset.c:106)
       by strset__add_str (strset.c:157)

      [...]

    ERROR SUMMARY: 5 errors from 2 contexts

With b23705e6afb6 there are no errors.

resolve_btfids statically links the in-tree tools/lib/bpf, so system
libbpf 1.7.0 is irrelevant, as you correctly noted. v7.1.1 predates
b23705e6afb6, which is why you are seeing the crash. It's been merged
into 7.2-rc1, so it will be in the 7.2 release.

I suggest you apply b23705e6afb6 for your build.

Let's drop this resolve_btfids patch, since the root cause has already been fixed.

Thank you!

[1] https://lore.kernel.org/bpf/20260523162722.2718940-1-cmllamas@google.com/

> 
> When resolve_btfids is compiled with musl and alpine's toolchain, then
> the following command segfaults roughly 50 % of the time:
> 
> tools/bpf/resolve_btfids/resolve_btfids --fatal_warnings --verbose --btf tmp_vmlinux1.BTF.1 tmp_vmlinux1
> 
> With a resolve_btfids compiled for glibc it does not segfault, but valgrind still reports invalid reads.
> 
>> Thanks!
> 
> [1] https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/libbpf/APKBUILD#L3
> 
> Best regards,
> Henrik Grimler


      reply	other threads:[~2026-07-07 19:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-19 22:49 [PATCH v2] resolve_btfids: preserve tag and parameter names when processing implicit args Aelin Reidel
2026-06-19 23:48 ` bot+bpf-ci
2026-06-26  5:26 ` Ihor Solodrai
2026-07-07  7:55   ` Henrik Grimler
2026-07-07 19:44     ` Ihor Solodrai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bec46089-abc2-418e-9b27-34dd9f6d1dde@linux.dev \
    --to=ihor.solodrai@linux.dev \
    --cc=aelin@mainlining.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=henrik@grimler.se \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=song@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox