Re: [PATCH bpf v2] bpf: fix NULL pointer dereference in bpf_task_from_vpid()

[bot+bpf-ci]

> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index b5314c9fed3c..890202361b53 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2912,6 +2912,9 @@ __bpf_kfunc struct task_struct *bpf_task_from_vpid(s32 vpid)
>  {
>  	struct task_struct *p;
>
> +	if (in_interrupt())
> +		return NULL;
> +

Does this check fully prevent the crash during task exit?

While this prevents the crash when an interrupt preempts an exiting task, it
appears it might not protect synchronous BPF tracing programs (like kprobes or
sched_switch tracepoints) executing in task context during do_exit().

Once __unhash_process() has cleared thread_pid, in_interrupt() returns false
in task context, but task_active_pid_ns(current) is still NULL. Wouldn't the
crash still occur in find_task_by_vpid() -> find_task_by_pid_ns() ->
find_pid_ns() -> idr_find(&NULL->idr)?

Additionally, in_interrupt() returns true in normal task context whenever
bottom-halves are disabled, such as inside a spin_lock_bh() region. Will this
cause bpf_task_from_vpid() to unexpectedly fail for valid tracing programs
attached to living tasks that happen to be holding a BH-disabled lock?

Could we verify the namespace directly instead to avoid these issues, perhaps
by checking if task_active_pid_ns(current) is NULL?

>  	rcu_read_lock();
>  	p = find_task_by_vpid(vpid);
>  	if (p)


---
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/27037807660