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
