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

[Mahe Tardy <mahe.tardy@gmail.com>]

On Tue, Oct 13, 2026 at 04:42:13PM +0000, sashiko-bot@kernel.org wrote:
> 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?

Indeed, in do_exit(), it seems we have this ordering:

	exit_nsproxy_namespaces(tsk);
	exit_task_work(tsk);

The first line will put nsproxy to NULL and the second will schedule any
remaining work and call the bpf callback set up with the wq. So this is
valid.

The fix would be to add some NULL check to prevent the panic in this
specific case (or see the next point).

> 
> [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?

Also agree, maybe socket creation should still be behind the check, I
think it's still useful to be able to connect and send from a workqueue
but preventing to create via workqueues might be a good limitation.

Let me send a v2 with create still using the runtime check, that should
fix this and the above issue.

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