Re: [RFC PATCH v8 2/4] virtio_ring: export virtqueue_reinit_vring() for noirq restore

[배성호/책임연구원/SW Platform(연)Advanced OS Task]

On Thu, May 7, 2026 at 10:45:20PM +0900, Sungho Bae wrote:

> +       if (virtqueue_is_packed(vq)) {
> +               virtqueue_reset_packed(vq);
> +       } else {
> +               /*
> +                * Split queue shadow index should match the visible avail
> +                * index when the queue is fully quiesced.
> +                */
> +               if (WARN_ON(vq->split.avail_idx_shadow !=
> +                       virtio16_to_cpu(vq->vq.vdev,
> +                                       vq->split.vring.avail->idx)))
> +                       return -EBUSY;

A security issue regarding malicious hosts has been raised from sashiko:
https://sashiko.dev/#/patchset/20260506162254.25576-1-baver.bae%40gmail.com?part=2

That is a good point.

However, I do not think this WARN_ON is meant to validate hostile or otherwise untrusted host input. The check is there to verify a guest-side invariant at reinitialization time: once the queue is fully quiesced and the transport/device side has already stopped or reset the queue, the split avail shadow index is expected to match the visible avail index.

If a compromised host can still modify the vring contents at that point, then this is not a problem specific to this WARN_ON. Such a host can already corrupt virtually any shared virtqueue state, so replacing this warning with a plain -EBUSY would not meaningfully improve robustness against that threat model.

In other words, this WARN_ON is intended to catch guest/driver state inconsistencies or violated call-site assumptions, not to provide protection against a malicious host. For the actual failure path, the code already returns -EBUSY after the warning.

I therefore think this is better treated as a debugging/invariant check than as validation of untrusted input.

Best regards,
Sungho Bae