Re: [PATCH v5 1/2] bpf, sockmap: handle spurious tcp_msg_wait_data() wakeup

[Nnamdi Onyeyiri <nnamdio@gmail.com>]

On Fri, Jul 17, 2026 at 05:01:46PM +0000, sashiko-bot@kernel.org wrote:
> 
> [Severity: High]
> This is a pre-existing issue in tcp_bpf_recvmsg_parser(), but this patch
> copies the same logic into tcp_bpf_recvmsg(). Does this create an unkillable
> infinite loop if the user calls recv() with a length of 0?
> 
> If a user waits for data to be queued and ensures an error state is set (for
> example, the peer sends a FIN setting RCV_SHUTDOWN), and then calls
> recv(fd, buf, 0, 0), sk_msg_recvmsg() immediately returns 0 since len is 0.
> 
> The code enters the if (!copied) block, hits the RCV_SHUTDOWN check, and
> because !sk_psock_queue_empty(psock) is true, it executes goto
> msg_bytes_ready.
> 
> Since len is 0, the cycle repeats immediately without releasing the socket
> lock or checking for signals, pegging the CPU and potentially causing a
> soft lockup. Is there a way to safely break out of this loop when len is 0?
> 

I don't think this is possible, as both tcp_bpf_recvmsg() and
tcp_bpf_recvmsg_parser() have an early return (before the loop) if len is 0.

> 
> [Severity: High]
> This is a pre-existing issue, but does tcp_bpf_recvmsg() propagate an
> incorrect -EFAULT to userspace when receiving a 0-length message?
> 
> If a BPF verdict program redirects a 0-length packet (such as an empty TCP
> FIN) to a sockmap socket, it is queued as an sk_msg with sge->length == 0.
> 
> When the user calls recv(), __sk_msg_recvmsg() in net/core/skmsg.c
> processes the element, sets copy = sge->length (which is 0), and bypasses
> copy_page_to_iter(). It then evaluates if (!copy).
> 
> Since copy is 0, it triggers copied = copied ? copied : -EFAULT, returning
> -EFAULT.
> 
> Because -EFAULT is not 0, tcp_bpf_recvmsg() bypasses the if (!copied) error
> handling block above and directly assigns ret = copied, returning the
> -EFAULT back to the syscall caller. Should this case return EOF (0) instead
> of -EFAULT?
> 

I can reproduce this in a selftest.  As this patchset is addressing
EAGAIN errors, I'll send patch for the EFAULT separately.