On Tue, Oct 06, 2026 at 06:12:08PM +0900, sungbyeongchan wrote: > 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
As far as I can tell, you are saying a device can confuse it's driver? So what? -- MST
