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

[Alan Maguire <almagui@kernel.org>]

On 10/23/26 9:42 AM, Mahe Tardy wrote:
> 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).
> 

I suppose one way out of this would be to forbid bind()ing to the privileged
port range; that would sidestep the issue I think. Hard to know how restrictive
that would be in terms of real use cases, what do you think?
>>
>>> 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
>