Re: [PATCH bpf v2 1/2] bpf: Fix kfunc implicit arg inject type detection to prevent invalid pointer deref

[Eduard Zingerman]

On Mon, 2026-06-01 at 07:42 +0000, bot+bpf-ci@xxxxxxxxxx wrote:
> > bpf: Fix kfunc implicit arg inject type detection to prevent invalid pointer deref
> > 
> > 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,
> > 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,
> > 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.
> 
> This looks like a fix for a real bug, but it does not carry a Fixes:
> tag.  Should it point at the change that introduced the implicit
> prog_aux argument handling, is_kfunc_arg_prog_aux() and KF_ARG_PROG_AUX_ID?
> 
> That code appears to come from "bpf: Support __magic prog_aux arguments
> for kfuncs" (Ihor Solodrai, lore message-id
> 20251029190113.3323406-5-ihor.solodrai@xxxxxxxxx).
> 
> The merged SHA could not be resolved from this repository, so the tag
> would need to be filled in by hand, for example:
> 
>   Fixes: <sha> ("bpf: Support __magic prog_aux arguments for kfuncs")
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26740141551

The robot (and b4 utility as well) is confused by the following
formatting quirk:

> ...
> Fix
> ---
> ...

The triple dash marks the start of the diff section of the patch.
Hence, when I apply this series the commit message is truncated after
this point.