[BUG] virtio_ring: VDUSE backend can corrupt split-ring free list

[sungbyeongchan <tjdqudcks0424@naver.com>]

Hello,

I found a split-virtqueue free-list corruption issue reachable from a
delegated VDUSE backend.

virtqueue_add_desc_split() records descriptor flags and next indexes in
the kernel-only desc_extra array before publishing the shared descriptor.
During completion, detach_buf_split_in_order() follows the shadow next
index but decides whether to continue by rereading the backend-writable
shared descriptor's NEXT flag.  A backend can therefore change the
detach length after publication.

I reproduced this twice on commit
ff47652a4b66c067c765a7ad464d930b5a9367cc using production VDUSE,
virtio_vdpa, and virtio-net paths in an isolated QEMU guest.  Initial
setup was performed by root, after which the backend ran as uid/gid
65534 with no capabilities and no-new-privileges.

Changing one published RX descriptor from WRITE to WRITE|NEXT caused
the host frontend to detach the adjacent active descriptor.  Completing
that adjacent descriptor normally then detached it again.  Six valid
completions increased num_free by seven and the following refill
published descriptor IDs 5,4,3,2,1,0,1, demonstrating deterministic
free-list corruption and duplicate descriptor allocation.

Four controls were clean, including no mutation, a one-descriptor
NEXT-clear case, an invalid used ID, and mutation after completion.  I
did not demonstrate an out-of-bounds host access, chosen-address access,
information disclosure, panic, code execution, or privilege escalation.

I tested replacing the shared flags read with extra[i].flags, which was
captured before publication.  The same forged workload then refilled six
unique descriptors and the normal control remained unchanged.  Build,
checkpatch, and fixed A/B validation passed.

I performed a best-effort public duplicate search through 2026-10-06
and found no exact public report for this post-publication NEXT mutation
and split-ring free-list corruption path.

This report was prepared with AI assistance and is being treated as
public under Documentation/process/security-bugs.rst.  A tested source
reproducer, logs, configuration, and proposed patch are available to the
maintainers on request; the reproducer is intentionally not attached to
this public report.

Assisted-by: LLM

Regards,
sungbyeongchan