Re: [PATCH bpf] bpf: Fix program BTF use-after-free in sleepable programs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Use-After-Free in bpf_prog_get_file_line() due to synchronous freeing of line info metadata.
- [High] Premature execution of module_put() allows module unloading while sleepable BPF programs are still executing.
--

commit 0ec9f868c2de818dd01ad433f26d1fe0d8574ac5
Author: Sanghyun Park <sanghyun.park.cnu@gmail.com>

bpf: Fix program BTF use-after-free in sleepable programs

Object kfunc calls embed metadata owned by the program BTF. A sleepable
program can remain active under Tasks Trace RCU after its last reference is
dropped, while program teardown releases the BTF through ordinary RCU. The
invocation can then dereference freed metadata in bpf_obj_new(). Move
btf_put() into __bpf_prog_put_rcu() to resolve this.

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 6874ba1424af0..26b05b454f18d 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -2451,7 +2452,6 @@ static void __bpf_prog_put_rcu(struct rcu_head *rcu)
>  static void __bpf_prog_put_noref(struct bpf_prog *prog, bool deferred)
>  {
>  	bpf_prog_kallsyms_del_all(prog);
> -	btf_put(prog->aux->btf);
>  	module_put(prog->aux->mod);

[Severity: High]
This is a pre-existing issue, but does leaving module_put() here allow the
module to be unloaded while sleepable BPF programs are still executing?

When a sleepable BPF program is attached to a function in a loadable kernel
module and its reference count drops to zero, __bpf_prog_put_noref()
synchronously executes module_put().

The BPF program itself may still be executing or sleeping, protected by the
Tasks Trace RCU grace period.

Dropping the module reference allows a concurrent rmmod to unload the target
module. Because module unloading uses synchronize_rcu() rather than
synchronize_rcu_tasks_trace(), it frees the module memory without waiting
for the sleepable BPF program to finish.

Can this lead to a kernel crash if the program attempts to return to the freed
module function?

>  	kvfree(prog->aux->jited_linfo);
>  	kvfree(prog->aux->linfo);

[Severity: High]
This is also a pre-existing issue, but can this synchronous freeing of the line
info metadata cause a use-after-free during a concurrent stack dump?

If CPU 0 executes a BPF program and triggers a stack dump, obtaining the
prog pointer via bpf_prog_ksym_find(), and CPU 1 concurrently unloads the
program, it will call __bpf_prog_put_noref(). CPU 1 then synchronously
executes kvfree(prog->aux->jited_linfo) and kvfree(prog->aux->linfo).

CPU 0 could then proceed to call bpf_prog_get_file_line() in
kernel/bpf/core.c using the found prog, dereferencing the prematurely freed
pointers:

kernel/bpf/core.c:bpf_prog_get_file_line() {
    ...
    linfo = &prog->aux->linfo[prog->aux->linfo_idx];
    jited_linfo = &prog->aux->jited_linfo[prog->aux->linfo_idx];
    ...
}

Should these frees also be deferred to the RCU callback?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901014829.3504342-2-sanghyun.park.cnu@gmail.com?part=1