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

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

[sungbyeongchan]

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

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

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

[성병찬]

Yes, the backend causes the driver to corrupt its own virtqueue
free-list accounting.

My concern was that, after privileged VDUSE setup, a delegated
unprivileged backend can trigger this by modifying a published
descriptor. However, my current reproducer demonstrates duplicate
descriptor allocation only. It does not demonstrate a host
memory-safety violation, cross-device impact, information disclosure,
or privilege escalation.

I therefore agree that the current evidence supports a robustness
issue rather than a confirmed security vulnerability.

Would a patch using the driver-owned desc_extra flags during detach
still be considered worthwhile, or is protection against this backend
behavior outside the intended threat model?

Regards,
sungbyeongchan

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

[Michael S. Tsirkin]

On Tue, Oct 06, 2026 at 06:39:23PM +0900, 성병찬 wrote:
> Yes, the backend causes the driver to corrupt its own virtqueue
> free-list accounting.
> 
> My concern was that, after privileged VDUSE setup, a delegated
> unprivileged backend can trigger this by modifying a published
> descriptor. However, my current reproducer demonstrates duplicate
> descriptor allocation only. It does not demonstrate a host
> memory-safety violation, cross-device impact, information disclosure,
> or privilege escalation.
> 
> I therefore agree that the current evidence supports a robustness
> issue rather than a confirmed security vulnerability.
> 
> Would a patch using the driver-owned desc_extra flags during detach
> still be considered worthwhile, or is protection against this backend
> behavior outside the intended threat model?
> 
> Regards,
> sungbyeongchan

It's outside a threat model but if the rest of data is coming from
desc_extra I don't see a good reason to read flags from the descriptor.
Will likely be better for cache, too.