All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vasiliy Kovalev" <kovalev@altlinux.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 5.10.y] bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()
Date: Tue, 21 Apr 2026 19:03:07 +0000	[thread overview]
Message-ID: <20260421190309.22AD6C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260421132839.38703-1-kovalev@altlinux.org>

Sashiko AI review found 1 potential issue(s):
- [High] Unconditional early return for `len == 0` in `tcp_bpf_recvmsg()` breaks UAPI semantics by masking socket errors, returning 0 instead of `-EAGAIN` for non-blocking sockets, and bypassing state checks.
--

commit 17cc1ee5a157715faa482ac2a4f167f9022cb333
Author: Liu Jian <liujian56@huawei.com>

bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()

This commit addresses a soft lockup issue where a 0-length recvmsg causes
an infinite loop in tcp_bpf_recvmsg_parser(). It fixes the issue by returning
0 early when the length is 0.

Link: https://lore.kernel.org/bpf/20230303080946.1146638-1-liujian56@huawei.com

> --- a/net/ipv4/tcp_bpf.c
> +++ b/net/ipv4/tcp_bpf.c
> @@ -277,6 +277,9 @@ static int tcp_bpf_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
>  	if (unlikely(flags & MSG_ERRQUEUE))
>  		return inet_recv_error(sk, msg, len, addr_len);
>  
> +	if (!len)
> +		return 0;

Does this unconditional early return bypass necessary socket state checks?

In the standard Linux TCP implementation, a 0-length receive is not an
immediate no-op. For instance, if the socket is non-blocking and empty,
tcp_recvmsg() normally returns -EAGAIN. If the socket has a pending error,
it returns that error, and if the socket is in TCP_LISTEN, it returns
-ENOTCONN.

By unconditionally returning 0 here, a non-blocking recv(0) on an empty
socket will return 0 instead of -EAGAIN. Since a 0 return value typically
indicates EOF (connection closed) to userspace applications, could this
cause applications to incorrectly assume the connection was closed and
drop it?

Would it be safer to delegate 0-length reads to the standard TCP
implementation by returning tcp_recvmsg() here instead, ensuring that
the existing UAPI error semantics are preserved?

> +
>  	psock = sk_psock_get(sk);
>  	if (unlikely(!psock))
>  		return tcp_recvmsg(sk, msg, len, nonblock, flags, addr_len);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260421132839.38703-1-kovalev@altlinux.org?part=1

      reply	other threads:[~2026-04-21 19:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21 13:28 [PATCH 5.10.y] bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser() Vasiliy Kovalev
2026-04-21 19:03 ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260421190309.22AD6C2BCB0@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kovalev@altlinux.org \
    --cc=sashiko@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.