Probe marks the device DRIVER_OK with virtio_device_ready() before
calling input_register_device(). If registration fails, the error path
cleared vi->ready and called del_vqs() while the device was still live,
so the device could keep DMA to queues that were already torn down.

Match remove/freeze: call virtio_reset_device() on that path before
tearing down the virtqueues.

Fixes: 271c865161c5 ("Add virtio-input driver.")
Cc: stable@vger.kernel.org
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
 drivers/virtio/virtio_input.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c
index deec24e8e..1a87be4c8 100644
--- a/drivers/virtio/virtio_input.c
+++ b/drivers/virtio/virtio_input.c
@@ -331,6 +331,7 @@ static int virtinput_probe(struct virtio_device *vdev)
 	spin_lock_irqsave(&vi->lock, flags);
 	vi->ready = false;
 	spin_unlock_irqrestore(&vi->lock, flags);
+	virtio_reset_device(vdev);
 err_mt_init_slots:
 	input_free_device(vi->idev);
 err_input_alloc:
-- 
2.43.0

On Wed, Aug 05, 2026 at 11:29:31AM +0800, Xiong Weimin wrote:
> Probe marks the device DRIVER_OK with virtio_device_ready() before
> calling input_register_device(). If registration fails, the error path
> cleared vi->ready and called del_vqs() while the device was still live,
> so the device could keep DMA to queues that were already torn down.
> 
> Match remove/freeze: call virtio_reset_device() on that path before
> tearing down the virtqueues.
> 
> Fixes: 271c865161c5 ("Add virtio-input driver.")
> Cc: stable@vger.kernel.org



for each of these patches: is this a real or a theoretical issue?
stable rules preclude the later kind.

> Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
> ---
>  drivers/virtio/virtio_input.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c
> index deec24e8e..1a87be4c8 100644
> --- a/drivers/virtio/virtio_input.c
> +++ b/drivers/virtio/virtio_input.c
> @@ -331,6 +331,7 @@ static int virtinput_probe(struct virtio_device *vdev)
>  	spin_lock_irqsave(&vi->lock, flags);
>  	vi->ready = false;
>  	spin_unlock_irqrestore(&vi->lock, flags);
> +	virtio_reset_device(vdev);
>  err_mt_init_slots:
>  	input_free_device(vi->idev);
>  err_input_alloc:
> -- 
> 2.43.0

On Wed, Aug 05, 2026 at 01:29:28AM -0400, Michael S. Tsirkin wrote:
> for each of these patches: is this a real or a theoretical issue?
> stable rules preclude the later kind.

For this virtio_input patch: theoretical for stable.

On the failing path, virtio_device_ready() has run, but
virtinput_fill_evt() has not, so the event queue still has no buffers.
I have no evidence of device DMA into torn-down queues here; the change
is lifecycle hygiene matching remove/freeze (clear DRIVER_OK before
del_vqs()).

I will drop Cc: stable on a v2 and keep the fix for mainline only.
I will answer the same question separately on the virtio_pci and
virtio_mmio threads.

Thanks,
Xiong

On Wed, Aug 05, 2026 at 01:29:28AM -0400, Michael S. Tsirkin wrote:
> for each of these patches: is this a real or a theoretical issue?
> stable rules preclude the later kind.

For this virtio_input patch: theoretical for stable.

On the failing path, virtio_device_ready() has run, but
virtinput_fill_evt() has not, so the event queue still has no buffers.
I have no evidence of device DMA into torn-down queues here; the change
is lifecycle hygiene matching remove/freeze (clear DRIVER_OK before
del_vqs()).

I will drop Cc: stable on a v2 and keep the fix for mainline only.
I will answer the same question separately on the virtio_pci and
virtio_mmio threads.

Thanks,
Xiong