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 <[email protected]> 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/[email protected]?part=1
