Messages in this thread |  | | From | 배성호/책임연구원/SW Platform(연)Adv anced OS Task <> | | Subject | Re: [RFC PATCH v8 2/4] virtio_ring: export virtqueue_reinit_vring() for noirq restore | | Date | Thu, 7 May 2026 14:02:02 +0000 |
| |
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 |  |