Re: [PATCH bpf-next 1/2] bpf: Add bpf_ksock_bind() kfunc

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

On Thu, Oct 22, 2026 at 06:45:34PM +0000, bot+bpf-ci@kernel.org wrote:
> > bpf: Add bpf_ksock_bind() kfunc
> 
> TL;DR: bpf_ksock_bind() called from a bpf_wq callback runs with kworker's full
> capabilities, so a CAP_BPF-only SYSCALL program may bypass the privileged-port
> (CAP_NET_BIND_SERVICE) check; the review asks whether to block it.

Honestly don't know if it makes sense to prevent it given you are
creating this kernel socket from a BPF context, if anyone with more
experience on this can help?

If the answer is yes, I imagine preventing bind() to run from a
workqueue is the easy answer so that all creds are respected as usual
and it's not a huge limitation (we mostly care about being able to
send()/sendto() from a wq).

> 
> > diff --git a/net/core/bpf_ksock.c b/net/core/bpf_ksock.c
> > index 37168f43c16c..c7b487d90cd0 100644
> > --- a/net/core/bpf_ksock.c
> > +++ b/net/core/bpf_ksock.c
> 
> [ ... ]
> 
> > @@ -178,6 +178,33 @@ bpf_ksock_create(const struct bpf_ksock_create_opts *opts, u32 opts__sz,
> >  	return NULL;
> >  }
> >
> > +/**
> > + * bpf_ksock_bind() - Bind a BPF kernel socket to a local address.
> 
> [ ... ]
> 
> > +__bpf_kfunc int bpf_ksock_bind(struct bpf_ksock *ks,
> > +			       const union bpf_ksock_addr *addr, u32 addr__sz)
> > +{
> > +	struct sockaddr_storage sa;
> > +	int addrlen;
> > +
> > +	addrlen = bpf_ksock_addr_to_sockaddr(addr, addr__sz, &sa);
> > +	if (addrlen < 0)
> > +		return addrlen;
> > +
> > +	return __sys_bind_socket(ks->sock, &sa, addrlen);
> > +}
> > +
> 
> Can the CAP_NET_BIND_SERVICE check for privileged ports be bypassed when
> this runs from a bpf_wq callback?
> 
> bpf_ksock_bind() is added to ksock_init_kfunc_btf_ids, the same set as
> bpf_ksock_connect().  Commit 60bbe76a3f9e ("bpf: Allow ksock connect/send
> calls from wq") made the kfuncs in this set callable from bpf_wq callbacks
> of SYSCALL programs, and tools/testing/selftests/bpf/progs/ksock_wq.c
> already calls bpf_ksock_connect() from such a callback.
> 
> bpf_wq_work() runs that callback in a kworker, where current->cred is
> init_cred with cap_effective set to CAP_FULL_SET (see init/init_task.c).
> 
> The bind path is:
> 
>   bpf_ksock_bind()
>     __sys_bind_socket()
>       security_socket_bind()
>       inet_bind() -> inet_bind_sk() -> __inet_bind()
> 
> and __inet_bind() then does:
> 
>     snum = ntohs(addr->sin_port);
>     err = -EACCES;
>     if (!(flags & BIND_NO_CAP_NET_BIND_SERVICE) &&
>         snum && inet_port_requires_bind_service(net, snum) &&
>         !ns_capable(net->user_ns, CAP_NET_BIND_SERVICE))
>             goto out;
> 
> __inet6_bind() has the same check.  With init_cred, cap_capable_helper()
> walks up to init_user_ns and finds the capability raised, so the check
> passes for any netns.
> 
> For example, a task holding only CAP_BPF can load a SYSCALL program, since
> is_net_admin_prog_type() does not ask for CAP_NET_ADMIN for that type.
> Such a program could bind its ksock to UDP port 53, 123 or 514 from a wq
> callback, while the same call made synchronously from the SYSCALL program
> returns -EACCES.  A bpf_task_work callback looks like it has the same
> problem in a different form, since the check would be evaluated against
> whichever task the work was scheduled on.
> 
> Commit 60bbe76a3f9e only argued about LSM checks ("bypassing LSM checks for
> BPF-created sockets could be acceptable"), and connect and send on a UDP
> ksock have no capability gate.  bind appears to be the first ksock
> operation that does, and the commit message does not address the wq
> context.
> 
> Should bpf_ksock_bind() refuse to run from kthread context, the way
> bpf_ksock_create() does with its PF_KTHREAD check?  Alternatively, should
> it be kept out of the set that is reachable from wq callbacks, or should
> the commit message state that bypassing the privileged-port check is
> intended?
> 
> No fix for this was found in the provided range; 76406b1f799f
> ("selftests/bpf: Test bpf_ksock_bind() kfunc") only adds tests.
> 
> 
> ---
> 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/39831790314