On 2026/08/28 21:37, Marc-André Lureau wrote:
Hi
On Fri, Aug 28, 2026 at 4:29 PM Akihiko Odaki
<[email protected]> wrote:
On 2026/08/28 21:26, Akihiko Odaki wrote:
On 2026/08/25 19:20, Marc-André Lureau wrote:
Hi,
While working on CVE-2026-66020 (which had a few revision on list), I
kept finding several places where virtio-gpu scanout and dmabuf
ownership was unclear.
The CVE comes from using a blob after RESOURCE_DETACH_BACKING has
unmapped its memory. Following that path also found stale dmabuf
references, duplicated scanout bookkeeping, and inconsistent cleanup
between display backends.
This series makes each virtio_gpu_scanout own its current dmabuf and
uses resource_id to track which resource it displays. It also makes
QemuDmaBuf own its file descriptors and moves GTK fence state out of the
dmabuf.
Those changes touch a lot of area and I have done basic testing with the
various backends. I would not recommend backporting them to stable:
there is a high risk of introducing regressions. Yet, I don't know how
to address all the problems uncovered by CVE-2026-66020 in a simple
patch series. Help welcome!
If you mean "all the problems", my coding agent tells there are some
problems remaining:
I forgot to note that I manually reviewed the claims.
I also think you can drop RFC. Though the series is large, each patch is
small and I think reasonable.
1. Vhost-user still has duplicate, incomplete DMA-BUF ownership.
VhostUserGPU retains its separate g->dmabuf[]. The contrib backend
disables a scanout using ordinary VHOST_USER_GPU_SCANOUT with zero
dimensions, but the QEMU frontend handles that by only calling
qemu_console_set_surface().
Although that changes con->scanout.kind, it neither releases g-
>dmabuf[id] nor invokes the frontend GL-disable callback. GTK/SDL can
therefore retain their private scanout mode and redraw the old buffer;
the wrapper and owned fd remain until another DMA-BUF message. Reset and
finalize also never free this array.
Separately, contrib’s virgl RESOURCE_UNREF destroys the renderer
resource without disabling scanouts using it. The in-process virgl
backend fixes precisely this case, but contrib does not.
2. GTK DMA-BUF texture release lacks the required GL context.
GTK’s release callback directly calls egl_dmabuf_release_texture(),
which calls glDeleteTextures() and then unconditionally forgets the
texture ID. Neither it nor the core release dispatcher establishes the
owning context.
This is reachable after another GTK console’s surface update leaves
EGL_NO_CONTEXT current. Deletion is then not guaranteed, yet the ID is
lost, leaking the GL import and backing. With another unshared context
current, a coincident texture name could be deleted from the wrong
context. SDL has the same missing-context pattern.
3. Rutabaga resource destruction remains incomplete.
virtio_gpu_rutabaga_resource_unref() calls Rutabaga unref and frees the
QEMU resource, but does not clean res->iov/res->addrs or remove a mapped
blob’s host-visible MemoryRegion. Only explicit RESOURCE_UNMAP_BLOB
removes that region.
Consequently, MAP_BLOB → RESOURCE_UNREF or reset can leave a
MemoryRegion pointing at storage destroyed by Rutabaga, as well as
pinned DMA mappings. This is adjacent to, rather than the original
scanout-detach CVE, but it is another unresolved blob-ownership problem.
...so there is still some work to be done.
Thanks for the analysis. Do you think we can review & apply this
series first before addressing the remaining issues? (and helping me
:)
For vhost-user and Rutabaga, yes: I think we can review this series
without making it solve every ownership problem first. Those paths are
separate and can be follow-ups.
It may be better to handle the GTK/SDL context issue before applying the
series, though. The callback already existed, but patches 7 and 10 add
release-on-disable and release-on-detach callers. They can invoke
glDeleteTextures() with no context, or with another console's context
current. A small additional patch should suffice; this does not require
keeping the series as RFC.
But when it comes to backporting, I think we can instead do focused
backporting to avoid extra trouble. Concretely, the patches you tagged
with "Fixes: CVE-2026-66020" can be backported, namely:
- "[PATCH 10/18] virtio-gpu: disable blob scanouts on mapping cleanup" and
- "[PATCH 18/18] virtio-gpu: fix use-after-free on blob cursor after
detach"
Cc: qemu-stable for those two only? even if there are still corner
cases addressed by the other patches)?
Yes. I don't think the other corner cases are worthwhile to fix risking
a regression.
But rechecking these patches, I found "[PATCH 18/18] virtio-gpu: fix
use-after-free on blob cursor after detach" has two dependencies on the
earlier patches:
- Patch 6 changes the signature of virtio_gpu_fini_udmabuf().
- Patch 17 allows removing the res->blob guard in
virtio_gpu_cleanup_mapping().
So I suggest:
- reordering the series to put patch 10 and patch 18 at the first,
- keeping the res->blob guard in patch 18, and
- dropping the res->blob guard in patch 17 instead.
Regards,
Akihiko Odaki
