Re: [PATCH bpf v3] 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..226c31ccb5d6 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2912,7 +2912,14 @@ __bpf_kfunc struct task_struct *bpf_task_from_vpid(s32 vpid)
>  {
>  	struct task_struct *p;
>
> +	if (in_interrupt())
> +		return NULL;

This isn't a bug, but a review comment on v3 about this in_interrupt()
check does not appear to have been answered.

The comment noted that in_interrupt() evaluates to irq_count(), so it
returns true not only in hardware and softirq context but also in normal
task context whenever bottom halves are disabled, such as inside
local_bh_disable() or spin_lock_bh().

Would this cause bpf_task_from_vpid() to return NULL for a valid BPF
program running in a BH-disabled task context, where current still has a
valid pid namespace?

Would using !in_task() instead filter out the asynchronous contexts
without rejecting BH-disabled task contexts?

  https://lore.kernel.org/bpf/20260606091941.1803115-1-rhkrqnwk98@xxxxxxxxx/

> +
>  	rcu_read_lock();
> +	if (!task_active_pid_ns(current)) {
> +		rcu_read_unlock();
> +		return NULL;
> +	}
>  	p = find_task_by_vpid(vpid);
>  	if (p)
>  		p = bpf_task_acquire(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/27058795186