Re: [RFC PATCH] vsock: keep SOCK_SEQPACKET message boundaries on interrupted send

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] vsock: infinite wait for oversized SOCK_SEQPACKET messages
--

commit 05c4fa125400dc8e76be397870f9646f61e7a31d
Author: Bartłomiej Dmitruk <bartlomiej.dmitruk@isec.pl>

vsock: keep SOCK_SEQPACKET message boundaries on interrupted send

A credit-limited SOCK_SEQPACKET send transmits fragments as credit becomes
available, and the VIRTIO_VSOCK_SEQ_EOM flag is set only on the fragment
where msg_data_left() reaches 0. If vsock_connectible_sendmsg() exits via
out_err after a partial send, the orphaned fragments are silently merged
into the next message.

> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> index f840498b58afb..3f7f01a7b8cbd 100644
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
> @@ -2250,9 +2250,16 @@ static int vsock_connectible_sendmsg(struct socket *sock, struct msghdr *msg,
>  
>  	while (total_written < len) {
>  		ssize_t written;
> +		/* For SEQPACKET wait until the whole remaining message fits, so
> +		 * it is enqueued atomically.  A credit-limited partial send that
> +		 * then errors out (e.g. -EINTR) would otherwise leave EOM-less
> +		 * fragments that the peer merges into the next message.
> +		 */
> +		s64 min_space = (sk->sk_type == SOCK_SEQPACKET) ?
> +				(s64)(len - total_written) : 1;
>  
>  		add_wait_queue(sk_sleep(sk), &wait);
> -		while (vsock_stream_has_space(vsk) == 0 &&
> +		while (vsock_stream_has_space(vsk) < min_space &&

[Severity: High]
Does this code introduce an infinite wait for oversized SOCK_SEQPACKET
messages?

If an application attempts to send a message larger than the transport's
maximum transmit buffer size, min_space will be set to the full message
length.

Because vsock_stream_has_space() is strictly upper-bounded by the buffer
allocation, the condition vsock_stream_has_space(vsk) < min_space will
never become false for these oversized messages.

The transport's -EMSGSIZE validation (such as in
virtio_transport_seqpacket_enqueue()) will never be reached because the
thread will block beforehand. A thread could hang indefinitely in an
interruptible sleep (unless a signal or timeout interrupts it) instead of
immediately returning an -EMSGSIZE error.

Could a malicious peer or guest VM advertise a very small peer_buf_alloc
and cause a host daemon that writes standard-sized messages to hang
unrecoverably?

>  		       sk->sk_err == 0 &&
>  		       !(sk->sk_shutdown & SEND_SHUTDOWN) &&
>  		       !(vsk->peer_shutdown & RCV_SHUTDOWN)) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917220101.55744-1-bartlomiej.dmitruk@isec.pl?part=1