Re: [PATCH bpf-next] bpf: allow ksock kfuncs call from wq

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] bpf: bpf_ksock_create causes NULL pointer deref on task exit
- [High] bpf: bpf_ksock_create in workqueue escapes network namespace
--

commit 34ed977b7943eebacf7e605dc8f26f2576ba2664
Author: Mahe Tardy <mahe.tardy@gmail.com>

bpf: allow ksock kfuncs call from wq

This commit relaxes the constraints on ksock kfuncs by removing the check
that ensures they are executed in a user task context. This change was
made to allow ksock kfuncs to be invoked from asynchronous workqueues,
bypassing the original LSM hook considerations.

> diff --git a/net/core/bpf_ksock.c b/net/core/bpf_ksock.c
> index e9943aeeadd32..21d5fd1eb403d 100644
> --- a/net/core/bpf_ksock.c
> +++ b/net/core/bpf_ksock.c
> @@ -73,16 +64,6 @@ bpf_ksock_create(const struct bpf_ksock_create_opts *opts, u32 opts__sz,
>  	struct bpf_ksock *ks;
>  	int err;
>  
> -	/*
> -	 * sock_create() derives the network namespace, credentials, and cgroup
> -	 * from current. Kernel threads, including BPF workqueue callbacks, do
> -	 * not carry the context of the task that invoked the BPF program.
> -	 */
> -	if (!bpf_ksock_has_user_task_context()) {
> -		err = -EOPNOTSUPP;
> -		goto err_out;
> -	}
> -

[Severity: High]
Does removing this check expose us to a NULL pointer dereference during task
exit?

If a sleepable BPF program running via task_work during do_exit() calls
bpf_ksock_create() after exit_nsproxy_namespaces() has cleared
current->nsproxy, it appears this could trigger a kernel panic.

Without the bpf_ksock_has_user_task_context() guard, bpf_ksock_create() will
now unconditionally call sock_create():

net/socket.c:sock_create() {
	return __sock_create(current->nsproxy->net_ns, family, type, protocol, res, 0);
}

Is it safe to allow sock_create() to dereference current->nsproxy here without
checking if it is NULL?

[Severity: High]
Additionally, does this change allow containerized workloads to escape their
network namespace?

When bpf_ksock_create() is invoked from a workqueue callback, the executing
context is a kthread.

Because sock_create() uses current->nsproxy->net_ns, a kthread will resolve
this to the host namespace (init_net), causing the socket to be created in the
host namespace rather than the container's netns.

Could this allow BPF programs inside containers to bypass container routing
and firewall policies by creating host-namespace sockets?

>  	if (!opts || opts__sz != sizeof(struct bpf_ksock_create_opts)) {
>  		err = -EINVAL;
>  		goto err_out;

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