Re: [PATCH] vsock/virtio: prevent workers from using deleted virtqueues

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect flush_work() ordering in virtio_vsock_remove() allows rx_work to be queued by a delayed send_pkt_work after rx_work has already been flushed, leading to a use-after-free when vsock is destroyed.
--

--- Patch [1]: [PATCH] vsock/virtio: prevent workers from using deleted virtqueues ---
commit fac9b600b273994b7593c604a6d3d0352d8dbee3
Author: Weiming Shi <bestswngs@gmail.com>

vsock/virtio: prevent workers from using deleted virtqueues

The RX, TX and event workers read their virtqueue pointers before taking
the mutex that protects the queue and its run flag. This patch reads each
worker's virtqueue under its mutex after confirming the queue is running,
preventing use-after-free of deleted virtqueues.

Cc: stable@vger.kernel.org

> diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
> index 57f2d6ec3ffc6..79cf19f589439 100644
> --- a/net/vmw_vsock/virtio_transport.c
> +++ b/net/vmw_vsock/virtio_transport.c
[ ... ]
> @@ -689,7 +690,8 @@ static void virtio_transport_rx_work(struct work_struct *work)
>  	} while (!virtqueue_enable_cb(vq));
>  
>  out:
> -	if (vsock->rx_buf_nr < vsock->rx_buf_max_nr / 2)
> +	if (vsock->rx_run &&
> +	    vsock->rx_buf_nr < vsock->rx_buf_max_nr / 2)
>  		virtio_vsock_rx_fill(vsock);
>  	mutex_unlock(&vsock->rx_lock);
>  }

[Severity: High]
This is a pre-existing issue, but is there a use-after-free risk in
virtio_vsock_remove() due to the flush_work() ordering?

In virtio_vsock_remove(), the flush sequence drains rx_work before
send_pkt_work:

    flush_work(&vsock->rx_work);
    flush_work(&vsock->tx_work);
    flush_work(&vsock->event_work);
    flush_work(&vsock->send_pkt_work);
    ...
    kfree(vsock);

Meanwhile, virtio_transport_send_pkt_work() can queue rx_work outside
the tx_lock:

out:
    mutex_unlock(&vsock->tx_lock);

    if (restart_rx)
        queue_work(virtio_vsock_workqueue, &vsock->rx_work);

If virtio_vsock_remove() flushes rx_work (which returns immediately if it
has not been queued yet), and then blocks waiting on send_pkt_work to finish,
could send_pkt_work queue rx_work just before completing?

This would leave rx_work pending in the workqueue after virtio_vsock_remove()
frees the vsock object, leading to memory corruption when the work executes.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727035804.1860862-1-bestswngs@gmail.com?part=1