TIPC stream send currently enters the transmit loop even when the user payload length is zero. This can build and transmit a header-only connection message. For local TIPC sockets, such messages are delivered synchronously through the loopback receive path. When this happens while socket backlog processing is being flushed, reply transmission can re-enter TIPC receive processing repeatedly and trigger an RCU stall. Make zero-length sends on connected SOCK_STREAM TIPC sockets a no-op after the existing connection/congestion wait has succeeded. Leave implicit connection setup and SOCK_SEQPACKET behavior unchanged. Fixes: 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") Cc: stable@vger.kernel.org Reported-by: syzbot+aa7d098bd6fa788fae8e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000cedbc405ae81531f@google.com/ Closes: https://syzkaller.appspot.com/bug?extid=aa7d098bd6fa788fae8e Signed-off-by: Cássio Gabriel --- net/tipc/socket.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/tipc/socket.c b/net/tipc/socket.c index 9329919fb07f..3c7838713d74 100644 --- a/net/tipc/socket.c +++ b/net/tipc/socket.c @@ -1585,6 +1585,8 @@ static int __tipc_sendstream(struct socket *sock, struct msghdr *m, size_t dlen) tipc_sk_connected(sk))); if (unlikely(rc)) break; + if (unlikely(!dlen && sk->sk_type == SOCK_STREAM)) + break; send = min_t(size_t, dlen - sent, TIPC_MAX_USER_MSG_SIZE); blocks = tsk->snd_backlog; if (tsk->oneway++ >= tsk->nagle_start && maxnagle && --- base-commit: 95084f1883a760e0d4290698346759d58e2b944a change-id: 20260505-tipc-zero-length-stream-stall-2c3741de2c93 Best regards, -- Cássio Gabriel