Re: [PATCH v2 1/2] vsock/virtio: read virtqueues under worker locks

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Flawed workqueue flush order in `virtio_vsock_remove` causes Use-After-Free when `virtio_transport_send_pkt_work` queues `rx_work`.
--

--- Patch [1]: [PATCH v2 1/2] vsock/virtio: read virtqueues under worker locks ---
commit c2d4498ec56e6055b57f65b66030241e0c52ce07
Author: Weiming Shi <bestswngs@gmail.com>

vsock/virtio: read virtqueues under worker locks

This commit ensures that virtqueues are read under their respective worker
locks after checking the run flag. This prevents a worker delayed across freeze
and restore from observing a running state while retaining a pointer to a
deleted queue.

Link: https://lore.kernel.org/r/20260727035804.1860862-1-bestswngs@gmail.com

> diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
> index 57f2d6ec3ffc6..a8e1dd95ba8c8 100644
> --- a/net/vmw_vsock/virtio_transport.c
> +++ b/net/vmw_vsock/virtio_transport.c
> @@ -346,12 +346,13 @@ static void virtio_transport_tx_work(struct work_struct *work)
>  	struct virtqueue *vq;
>  	bool added = false;
>  
> -	vq = vsock->vqs[VSOCK_VQ_TX];
>  	mutex_lock(&vsock->tx_lock);
>  
>  	if (!vsock->tx_run)
>  		goto out;
>  
> +	vq = vsock->vqs[VSOCK_VQ_TX];
> +
>  	do {
>  		struct sk_buff *skb;
>  		unsigned int len;

[ ... ]

> @@ -634,13 +635,13 @@ static void virtio_transport_rx_work(struct work_struct *work)
>  		container_of(work, struct virtio_vsock, rx_work);
>  	struct virtqueue *vq;
>  
> -	vq = vsock->vqs[VSOCK_VQ_RX];
> -
>  	mutex_lock(&vsock->rx_lock);
>  
>  	if (!vsock->rx_run)
>  		goto out;
>  
> +	vq = vsock->vqs[VSOCK_VQ_RX];
> +
>  	do {
>  		virtqueue_disable_cb(vq);
>  		for (;;) {

[Severity: Critical]
This is a pre-existing issue, but does the workqueue flush order in
virtio_vsock_remove() risk a use-after-free if virtio_transport_send_pkt_work()
queues rx_work concurrently?

Looking at virtio_vsock_remove(), works are flushed in this order:

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

If virtio_transport_send_pkt_work() runs concurrently, could it be preempted
after dropping the tx_lock, but before queuing rx_work?

virtio_transport_send_pkt_work() handles this here:

    mutex_unlock(&vsock->tx_lock);

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

If preempted there, virtio_vsock_remove() would skip flush_work(&vsock->rx_work)
because it isn't queued yet. It would then flush send_pkt_work, blocking until
virtio_transport_send_pkt_work() resumes.

When virtio_transport_send_pkt_work() resumes, it queues rx_work and finishes.
virtio_vsock_remove() would then complete and free the vsock object via
kfree(vsock), leaving the newly queued rx_work pointing to freed memory.

Could the flush of rx_work be moved after the flush of send_pkt_work to handle
this race?

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