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

[Kumar Kartikeya Dwivedi]

On Sun Jun 7, 2026 at 12:05 PM CEST, Sechang Lim wrote:
> On Sun, Jun 07, 2026 at 10:44:41AM +0200, Kumar Kartikeya Dwivedi wrote:
>>>  kernel/bpf/helpers.c | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> 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 seems too broad, I would just drop this hunk. It seems unrelated to the fix.
>>IIUC we only need the bit below to prevent the original NULL deref.
>>
>>pw-bot: cr
>>
>>>  	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);
>>
>
> Right, the NULL check alone fixes the crash. The async-context guard was
> added on Yonghong's v1 request: in softirq current is unrelated to the
> packet, so the looked-up task is meaning less even without the crash.
>
> Drop it entirely, or keep that intent with a narrower predicate?
> in_interrupt() is also true under spin_lock_bh(), so !in_task() would be
> more precise.

Drop it. I think there are contexts where tracing programs use it, may run with
interrupts disabled, but current still remains meaningful.