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
