Re: [PATCH bpf-next] bpf, unix: Guard sk_msg-dependent code behind CONFIG_NET_SOCK_MSG

[Jakub Sitnicki <jakub@cloudflare.com>]

On Mon, Jun 22, 2026 at 01:17 PM GMT, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] Calling recvmsg() on a UNIX socket added to a BPF sockmap causes a NULL pointer dereference when CONFIG_NET_SOCK_MSG is disabled.
> --
>
> commit 95825431b208bd3fb6f5fe58d504bdcb560273c9
> Author: Jakub Sitnicki <jakub@cloudflare.com>
>
> bpf, unix: Guard sk_msg-dependent code behind CONFIG_NET_SOCK_MSG
>
> This commit conditionally compiles the assignment of recvmsg and 
> sock_is_readable in AF_UNIX BPF protocol rebuilding functions, guarding them
> behind CONFIG_NET_SOCK_MSG.
>
>> diff --git a/net/unix/unix_bpf.c b/net/unix/unix_bpf.c
>> index f86ff19e9764d..5289a04b4993f 100644
>> --- a/net/unix/unix_bpf.c
>> +++ b/net/unix/unix_bpf.c
>
> [ ... ]
>
>> @@ -107,8 +109,10 @@ static void unix_dgram_bpf_rebuild_protos(struct proto *prot, const struct proto
>>  {
>>  	*prot        = *base;
>>  	prot->close  = sock_map_close;
>> +#ifdef CONFIG_NET_SOCK_MSG
>>  	prot->recvmsg = unix_bpf_recvmsg;
>>  	prot->sock_is_readable = sk_msg_is_readable;
>> +#endif
>>  }
>
> [Severity: Critical]
> If CONFIG_NET_SOCK_MSG is disabled but CONFIG_BPF_SYSCALL is enabled,
> doesn't this leave prot->recvmsg as NULL?
>
> When a UNIX datagram socket is added to a sockmap, its protocol is updated to
> the rebuilt BPF protocol. If a user then calls recvmsg(), unix_dgram_recvmsg
> checks if the protocol has been overridden:
>
> net/unix/af_unix.c:unix_dgram_recvmsg() {
> 	...
> 	if (prot != &unix_dgram_proto)
> 		return prot->recvmsg(sk, msg, size, flags);
> 	...
> }
>
> Will this cause a NULL pointer dereference since prot->recvmsg is never
> assigned for the rebuilt protocol when CONFIG_NET_SOCK_MSG is disabled?

Right, my bad. I will switch the check to `prot->recvmsg != NULL` since
unix_{dgram,stream}_proto don't set it.