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

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

[Weiming Shi]

Commit bd50c5dc182b ("vsock/virtio: add support for device
suspend/resume") made the *_run flags transition from false to true when
restore installs replacement virtqueues.  The RX, TX and event workers
read their virtqueue before locking and checking the corresponding flag,
so a worker delayed across freeze and restore can observe the replacement
queue's running state while retaining a pointer to the deleted queue.

Read each virtqueue under its mutex after checking the run flag, keeping
the pointer and state in the same queue generation.

Fixes: bd50c5dc182b ("vsock/virtio: add support for device suspend/resume")
Cc: stable@vger.kernel.org
Reported-by: Xiang Mei <xmei5@asu.edu>
Link: https://lore.kernel.org/r/20260727035804.1860862-1-bestswngs@gmail.com
Assisted-by: OpenAI-Codex:gpt-5
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
 net/vmw_vsock/virtio_transport.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 57f2d6ec3ffc..a8e1dd95ba8c 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;
@@ -451,13 +452,13 @@ static void virtio_transport_event_work(struct work_struct *work)
 		container_of(work, struct virtio_vsock, event_work);
 	struct virtqueue *vq;
 
-	vq = vsock->vqs[VSOCK_VQ_EVENT];
-
 	mutex_lock(&vsock->event_lock);
 
 	if (!vsock->event_run)
 		goto out;
 
+	vq = vsock->vqs[VSOCK_VQ_EVENT];
+
 	do {
 		struct virtio_vsock_event *event;
 		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 (;;) {
-- 
2.55.0

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

[sashiko-bot]

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