On 2026/07/16 17:31, Marc-André Lureau wrote:
Hi
On Thu, Jul 16, 2026 at 12:20 PM Marc-André Lureau
<[email protected]> wrote:
Hi
On Thu, Jul 16, 2026 at 12:04 PM Akihiko Odaki
<[email protected]> wrote:
On 2026/07/16 16:37, Akihiko Odaki wrote:
On 2026/07/16 5:10, [email protected] wrote:
From: Marc-André Lureau <[email protected]>
Validate that the framebuffer stride is at least width * bytes_per_pixel
in both virtio_gpu_scanout_blob_to_fb() and virtio_gpu_do_set_scanout().
A guest can set a very small stride while using a large width. The total
size check (offset + stride * height <= blob_size) passes because
stride * height is small, but pixman reads width * bytes_per_pixel per
row, causing heap OOB reads. The leaked data is rendered to the host
display.
The check is added in virtio_gpu_do_set_scanout() to cover all paths:
blob scanout, non-blob scanout and migration post_load. The additional
early check in virtio_gpu_scanout_blob_to_fb() rejects invalid blob
configurations early.
Fixes: CVE-2026-63109
Fixes: 144bd171c837 ("virtio-gpu: Support blob scanout using dmabuf fd")
I cannot resolve commit 144bd171c837. Apparently the bug was introduced
by commit 7b5574225429 ("hw/display: check frame buffer can hold blob").
oh yes, that was an earlier version from a development branch, thanks..
I'd rather reference 32db3c63ae11 ("virtio-gpu: Add
virtio_gpu_set_scanout_blob") that introduced the issue
I don't think commit 32db3c63ae11 ("virtio-gpu: Add
virtio_gpu_set_scanout_blob") introduced this particular issue. Its
original bounds check accounted for the complete last row:
offset + stride * (height - 1) + bytes_per_pixel * width
So, a short stride could make rows overlap, but Pixman would still
remain within the validated blob extent.
Commit 7b5574225429 ("hw/display: check frame buffer can hold blob")
changed the check to offset + stride * height, which underestimates
Pixman's access when stride < width * bytes_per_pixel. That change made
the described OOB read possible, so I think it is the appropriate Fixes:
commit.
Regards,
Akihiko Odaki
