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

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

[Bartłomiej Dmitruk]

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 -- notably the non-terminal -EINTR path
(signal_pending while blocked for credit), but also sk_err / peer
RCV_SHUTDOWN -- the already-transmitted fragments carry no EOM.  The
receiver only advances msg_count / sets msg_ready on an EOM skb, so the
orphaned fragments are silently merged into the *next* message, violating
SOCK_SEQPACKET atomicity.

Reproduced on vsock_loopback: an -EINTR-aborted partial send of 'A's is
merged into the next 'B' message; recv() returns one [A...][B...] message
instead of just the 'B' message (reproducer + before/after below the ---).

Since a SEQPACKET message is bounded by min(peer_buf_alloc, buf_alloc)
(EMSGSIZE gate in virtio_transport_seqpacket_enqueue()), the sender can
wait for room for the whole remaining message before enqueuing, so the
message is committed atomically or not at all; an error while waiting then
leaves nothing on the wire.  SOCK_STREAM behaviour is unchanged
(min_space == 1 reproduces the old "wait while space == 0").

RFC: an alternative is to close a partially-sent message with an explicit
EOM on the error path; feedback on the preferred approach welcome.

Signed-off-by: Bartłomiej Dmitruk <bartlomiej.dmitruk@isec.pl>
---

Testing (vsock_loopback, unprivileged, single process; reproducer in
t_vuln004.c): receiver buf_alloc=16384; a 14000-byte message is left unread
to shrink credit to 2384; an 8000-byte message is sent with alarm(1) so the
send is interrupted (-EINTR) after a partial 2384-byte fragment; the 14000
message is drained; then a 1000-byte message is sent.

  before: recv() returns one 3384-byte message = 2384 'A' (orphan) + 1000 'B'
  after:  recv() returns one 1000-byte message = 1000 'B'   (boundary intact)

Normal SEQPACKET send/recv (the 14000- and 1000-byte whole messages) works
unchanged.

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -2250,9 +2250,16 @@
 
 	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 &&
 		       sk->sk_err == 0 &&
 		       !(sk->sk_shutdown & SEND_SHUTDOWN) &&
 		       !(vsk->peer_shutdown & RCV_SHUTDOWN)) {

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

[sashiko-bot]

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