Re:Re: [PATCH bpf v3 1/2] bpf: Fix kfunc implicit arg inject type detection to prevent invalid pointer deref
From: chenyuan
Date: Thu Jun 04 2026 - 05:21:21 EST
Hi Ihor：
> Could you please elaborate on the "incorrect type information" generated
by pahole 1.30?
I extracted the .BTF and .BTF.base sections from the same
bpf_testmod.ko built with pahole 1.30 vs 1.31 to compare:
# pahole 1.30 — bpf_prog_aux in split BTF, NOT in base
$ bpftool btf dump file btf_1_30_base.bin | grep bpf_prog_aux
(empty)
$ bpftool btf dump -B btf_1_30_base.bin file btf_1_30.bin | grep aux
[3172] STRUCT 'bpf_prog_aux' size=2016 vlen=87
# pahole 1.31 — bpf_prog_aux in base BTF, NOT in split
$ bpftool btf dump file btf_1_31_base.bin | grep bpf_prog_aux
[10] STRUCT 'bpf_prog_aux' size=2016 vlen=0
$ bpftool btf dump -B btf_1_31_base.bin file btf_1_31.bin | grep aux
(empty)
pahole 1.30 places struct bpf_prog_aux in the module's split BTF
(instead of the distilled base). pahole 1.31 correctly moves it to
the base BTF.
> Do you know how this happens? Is it a bug in pahole or in resolve_btfids?
It's a pahole issue. pahole's BTF encoder decides which types go into
.BTF.base (distilled base) vs .BTF (split). In 1.30, types
referenced by kfunc declarations were not being correctly identified as
vmlinux types for the distilled base, so they ended up as "new" types in
the split BTF instead.
> I have a suspicion we might not need changes in the verifier to fix this.
The kernel's BTF dedup during module loading only operates on types in
the distilled base (.BTF.base), merging them with vmlinux BTF.
Types in the split BTF (.BTF) are treated as module-local and
assigned fresh IDs — they are never matched against vmlinux.
This means when a toolchain bug puts a vmlinux type into split BTF
instead of the base , the kernel has no mechanism to detect or fix it.
btf_types_are_same() compares pointers across two different BTF
objects — always fails for this case. is_kfunc_arg_prog_aux()
returns false, the argument is silently skipped, and the kfunc
dereferences uninitialized register state.
While pahole 1.31 fixes the root cause, the verifier change is a
safety net: a crash becomes a clean rejection regardless of which
toolchain component introduces a BTF mismatch. This is defense-in-depth,
not a replacement for the toolchain fix.
At 2026-06-03 02:52:39, "Ihor Solodrai" <ihor.solodrai@xxxxxxxxx> wrote:
>On 6/2/26 1:58 AM, chenyuan_fl@xxxxxxx wrote:
>> From: Yuan Chen <chenyuan@xxxxxxxxxx>
>>
>> When a module kfunc declares an implicit struct bpf_prog_aux * argument,
>> the verifier must identify it so the kernel injects env->prog->aux into
>> the correct register at runtime. The original check used
>> is_kfunc_arg_prog_aux() which calls btf_types_are_same() to compare the
>> module BTF type against vmlinux.
>>
>> Root Cause
>>
>> This issue was triggered by pahole 1.30 generating module BTF with
>> incorrect type information, which caused the kernel's distilled base
>> BTF deduplication for modules to fail. As a result, the module retained
>> its own copy of struct bpf_prog_aux with a different BTF ID than
>> vmlinux's definition. While pahole 1.31 fixed the BTF generation issue,
>
>Hi Yuan,
>
>Could you please elaborate on the "incorrect type information" generated
>by pahole 1.30?
>
>My understanding is, the symptom of the problem you're trying to fix is
>that module BTF with custom kfuncs with KF_IMPLICIT_ARGS ends up with a
>copy of an arg type, instead of referencing the BTF ID in kernel BTF.
>
>Do you know how this happens? Is it a bug in pahole or in resolve_btfids?
>
>I have a suspicion we might not need changes in the verifier to fix this.
>Might be wrong of course, would appreciate a bit more details.
>
>> the kernel must be robust against such inconsistencies: a BTF mismatch
>> should result in a clean rejection, not a kernel crash or information
>> disclosure.
>>
>> When the distilled base dedup fails and btf_types_are_same() cannot
>> match the module's bpf_prog_aux type against vmlinux's,
>
>Dedup happens in pahole, but distill_base is done in resolve_btfids.
>I think distill_base is supposed to remove the (copy of) target type from
>module BTF. Can you confirm that it doesn't?
>
>> is_kfunc_arg_prog_aux() returned false and the code fell through
>> silently without setting arg_prog. The kfunc then received whatever
>> value was in the argument register and dereferenced it as a
>> bpf_prog_aux pointer, leading to:
>>
>> BUG: kernel invalid pointer dereference, address: 00000000000009e2
>> RIP: bpf_prog_get_assoc_struct_ops+0xa/0xc0
>> RDI: 0x000000000000046d (stale register value)
>>
>> In the observed crash the stale value was the process PID, causing a
>> dereference within the unmapped NULL page. However, an attacker able
>> to control the register value -- for example by writing a BPF program
>> that explicitly sets R2 before calling a KF_IMPLICIT_ARGS kfunc --
>> could redirect the dereference to arbitrary kernel memory, turning
>> this into an information disclosure. The fix ensures the verifier
>> either validates and injects the correct bpf_prog_aux pointer, or
>> rejects the program outright -- no silent fallthrough that could
>> be exploited.
>>
>> Crash Stack Trace
>>
>> PID: 1133 TASK: ffff8881057d3900 CPU: 3 COMMAND: "test_progs"
>> #0 machine_kexec at ffffffff812f6e26
>> #1 __crash_kexec at ffffffff8145a788
>> #2 crash_kexec at ffffffff8145ac24
>> #3 oops_end at ffffffff812bb67c
>> #4 page_fault_oops at ffffffff813053a1
>> #5 exc_page_fault at ffffffff828e60a1
>> #6 asm_exc_page_fault at ffffffff810012a6
>> [exception RIP: bpf_prog_get_assoc_struct_ops+10]
>> RIP: ffffffff815c024a RSP: ffffc90001b57e48 RFLAGS: 00010283
>> RAX: ffff8881057d3900 RBX: ffffc90001b57e68 RCX: ffff8881057d3900
>> RDX: 0000607d4d1768b8 RSI: 000000000000046d RDI: 000000000000046d
>> #7 bpf_kfunc_multi_st_ops_test_1_assoc at ffffffffc0013a85 [bpf_testmod]
>> #8 bpf_trace_run2 at ffffffff814f8332
>> #9 __traceiter_sys_enter at ffffffff81415f45
>> #10 trace_syscall_enter at ffffffff81416735
>> #11 do_syscall_64 at ffffffff828e06a1
>>
>> Fix
>>
>> Split the combined is_kfunc_arg_ignore() || is_kfunc_arg_implicit()
>> check in check_kfunc_args() so that an implicit argument reaching
>> is_kfunc_arg_implicit() without being handled by a prior handler is
>> rejected with -EFAULT, instead of silently skipped. Recognized cases:
>>
>> - struct bpf_prog_aux * : is_kfunc_arg_prog_aux()
>> - __ign suffix args : is_kfunc_arg_ignore()
>> - list_push/rbtree_add : is_bpf_list_push_kfunc() / is_bpf_rbtree_add_kfunc()
>>
>> Suggested-by: Eduard Zingerman <eddyz87@xxxxxxxxx>
>> Fixes: 64e1360524b9 ("bpf: Verifier support for KF_IMPLICIT_ARGS")
>> Signed-off-by: Yuan Chen <chenyuan@xxxxxxxxxx>
>> ---
>> kernel/bpf/verifier.c | 15 ++++++++++++++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 8dd79b735a69..55c74d064e4e 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -11916,9 +11916,22 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>> continue;
>> }
>>
>> - if (is_kfunc_arg_ignore(btf, &args[i]) || is_kfunc_arg_implicit(meta, i))
>> + if (is_kfunc_arg_ignore(btf, &args[i]))
>> continue;
>>
>> + if (is_kfunc_arg_implicit(meta, i)) {
>> + /* list_push / rbtree_add kfuncs have implicit args
>> + * (e.g. 'off' parameter) handled during verification
>> + * in bpf_fixup_kfunc_call(). Don't flag them.
>> + */
>> + if (is_bpf_list_push_kfunc(meta->func_id) ||
>> + is_bpf_rbtree_add_kfunc(meta->func_id))
>> + continue;
>> + verbose(env, "%s unrecognized implicit argument, possible BTF mismatch\n",
>> + reg_arg_name(env, argno));
>> + return -EFAULT;
>> + }
>> +
>> t = btf_type_skip_modifiers(btf, args[i].type, NULL);
>>
>> if (btf_type_is_scalar(t)) {