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

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The patch prevents a NULL pointer dereference in `bpf_task_from_vpid()`, but leaves the root vulnerability unpatched in `find_pid_ns()` and `find_task_by_vpid()`, exposing other callers like `trace_user_stack_print()` to the exact same crash.
- [High] `bpf_task_from_vpid()` uses `current` to determine the target PID namespace, which produces arbitrary, non-deterministic results when called from interrupt/network BPF programs.
--

commit 061d0db0a968fb39f30d4aaead03a668556d0e21
Author: Sechang Lim <rhkrqnwk98@gmail.com>

bpf: fix NULL pointer dereference in bpf_task_from_vpid()
    
bpf_task_from_vpid() looks up a task in the pid namespace of the current
task. This patch adds a check to bail out when current has no pid namespace
to avoid a NULL pointer dereference in find_pid_ns().

> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index b5314c9fed3cf..4646a915bf98c 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2913,6 +2913,10 @@ __bpf_kfunc struct task_struct *bpf_task_from_vpid(s32 vpid)
>  	struct task_struct *p;
>  
>  	rcu_read_lock();
> +	if (!task_active_pid_ns(current)) {
> +		rcu_read_unlock();
> +		return NULL;
> +	}

[Severity: High]
This is a pre-existing issue, but while this patch prevents the crash in
bpf_task_from_vpid(), does it leave other callers of find_task_by_vpid()
vulnerable to the exact same NULL pointer dereference?

find_task_by_vpid() evaluates task_active_pid_ns(current) and passes the
result directly to find_pid_ns():

kernel/pid.c:find_pid_ns() {
        return idr_find(&ns->idr, nr);
}

If current has cleared its thread_pid during do_exit(), the namespace
pointer is NULL, and find_pid_ns() unconditionally dereferences it.

Other callers like trace_user_stack_print() in kernel/trace/trace_output.c
can still trigger this crash. For example, if the kernel oopses inside
do_exit() after detach_pid(), ftrace_dump_on_oops() can be invoked in a
panic context. If the trace buffer contains a user stack entry,
trace_user_stack_print() calls find_task_by_vpid(), potentially triggering
a recursive double-fault that prevents the panic log from flushing.

Would it be safer to add the NULL check directly inside find_pid_ns()
or find_task_by_vpid() instead?

[Severity: High]
This isn't a bug introduced by this patch, but does the use of current here
lead to arbitrary results for BPF programs running in interrupt context?

This kfunc is available for program types like cgroup_skb and xdp, which
can run in softirq or hardware interrupt context. In these contexts, current
points to whatever random task happened to be interrupted by the packet.

Since bpf_task_from_vpid() looks up the virtual PID relative to
task_active_pid_ns(current), won't passing the same vpid for the same
packet look up the PID in a completely random container or root namespace?

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

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603204206.773482-1-rhkrqnwk98@gmail.com?part=1