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

[Michael S. Tsirkin]

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