<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/virtio/virtgpu_vq.c, branch v6.6.150</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.150</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.150'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-08-03T09:15:24+00:00</updated>
<entry>
<title>drm/virtio: bound EDID block reads to the response buffer</title>
<updated>2026-08-03T09:15:24+00:00</updated>
<author>
<name>Bryam Vargas</name>
<email>hexlabsecurity@proton.me</email>
</author>
<published>2026-06-21T02:43:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9fc2a017c5d597937e0c28b9a9669844aa796c42'/>
<id>urn:sha1:9fc2a017c5d597937e0c28b9a9669844aa796c42</id>
<content type='text'>
commit 4e1a53892ba7f8a3e1da6bfc53c83ae7c812dccd upstream.

virtio_get_edid_block() validates the read offset only against the
device-supplied resp-&gt;size field, never against the fixed-size resp-&gt;edid
array. The EDID block index is driven by the device-supplied extension
count, so a malicious virtio-gpu backend can advertise a large size
together with a high block count and read far past the array into adjacent
kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds
read / info leak).

Also reject any read whose end exceeds the size of the edid array.
Conforming EDID responses stay within the array and are unaffected.

Fixes: b4b01b4995fb ("drm/virtio: add edid support")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas &lt;hexlabsecurity@proton.me&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patch.msgid.link/20260620-b4-disp-22bba7bf-v1-1-b95924cee742@proton.me
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/virtio: fix deadlock in display_info_cb by removing hotplug from dequeue worker</title>
<updated>2026-08-03T09:15:10+00:00</updated>
<author>
<name>Ryosuke Yasuoka</name>
<email>ryasuoka@redhat.com</email>
</author>
<published>2026-07-13T13:01:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=30e439a141d2c9687582a35fbf90bd3da594f506'/>
<id>urn:sha1:30e439a141d2c9687582a35fbf90bd3da594f506</id>
<content type='text'>
[ Upstream commit d1b894c5bbb3fee0012bd14356286dc2384e8213 ]

A probe-time deadlock can occur between the dequeue worker and
drm_client_register(). During probe, drm_client_register() holds
clientlist_mutex and calls the fbdev hotplug callback, which triggers an
atomic commit that ends up sleeping in virtio_gpu_queue_ctrl_sgs()
waiting for virtqueue space. The dequeue worker that would free that
space calls virtio_gpu_cmd_get_display_info_cb(), which invokes
drm_kms_helper_hotplug_event() -&gt; drm_client_dev_hotplug(), attempting
to acquire the same clientlist_mutex. Since wake_up() is only called
after the resp_cb loop, the probe thread is never woken and both threads
deadlock.

Fix this by removing the hotplug notification from
virtio_gpu_cmd_get_display_info_cb(). The display data (outputs[i].info)
is still updated synchronously in the callback.

For the init path, drm_client_register() already fires an initial
hotplug when the client is registered, which picks up the connector
state updated by display_info_cb.

For the runtime config_changed path, add a wait_event_timeout() in
config_changed_work_func() so that display_info_cb updates the connector
data before the hotplug notification is sent. Also replace
drm_helper_hpd_irq_event() with drm_kms_helper_hotplug_event() since
virtio-gpu never calls drm_kms_helper_poll_init() and thus
drm_helper_hpd_irq_event() always returns false without doing anything.

Fixes: 27655b9bb9f0 ("drm/client: Send hotplug event after registering a client")
Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
Suggested-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Ryosuke Yasuoka &lt;ryasuoka@redhat.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patch.msgid.link/20260713-virtiogpu_syzbot-v2-1-2958fa37d46d@redhat.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge v6.3-rc4 into drm-next</title>
<updated>2023-03-29T14:00:23+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2023-03-29T14:00:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=82bbec189ab34873688484cd14189a5392946fbb'/>
<id>urn:sha1:82bbec189ab34873688484cd14189a5392946fbb</id>
<content type='text'>
I just landed the fence deadline PR from Rob that a bunch of drivers
want/need to apply driver-specific patches. Backmerge -rc4 so that
they don't have to be stuck on -rc2 for no reason at all.

Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
</entry>
<entry>
<title>Merge drm/drm-fixes into drm-misc-fixes</title>
<updated>2023-03-13T09:14:05+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2023-03-13T09:14:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b3c9a04135bdbd3aabd5e9534bad0fe6df505f8a'/>
<id>urn:sha1:b3c9a04135bdbd3aabd5e9534bad0fe6df505f8a</id>
<content type='text'>
Backmerging to get latest upstream.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
</content>
</entry>
<entry>
<title>drm/virtio: use strscpy() to instead of strncpy()</title>
<updated>2023-02-26T23:58:50+00:00</updated>
<author>
<name>Xu Panda</name>
<email>xu.panda@zte.com.cn</email>
</author>
<published>2022-12-07T01:13:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8ac752463390882a5e73d85b141b68d5c259652d'/>
<id>urn:sha1:8ac752463390882a5e73d85b141b68d5c259652d</id>
<content type='text'>
The implementation of strscpy() is more robust and safer.
That's now the recommended way to copy NUL terminated strings.

Signed-off-by: Xu Panda &lt;xu.panda@zte.com.cn&gt;
Signed-off-by: Yang Yang &lt;yang.yang29@zte.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/202212070913161959936@zte.com.cn
</content>
</entry>
<entry>
<title>drm/virtio: Pass correct device to dma_sync_sgtable_for_device()</title>
<updated>2023-02-26T23:39:24+00:00</updated>
<author>
<name>Oleksandr Tyshchenko</name>
<email>oleksandr_tyshchenko@epam.com</email>
</author>
<published>2023-02-24T15:34:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a54bace095d00e9222161495649688bc43de4dde'/>
<id>urn:sha1:a54bace095d00e9222161495649688bc43de4dde</id>
<content type='text'>
The "vdev-&gt;dev.parent" should be used instead of "vdev-&gt;dev" as a device
for which to perform the DMA operation in both
virtio_gpu_cmd_transfer_to_host_2d(3d).

Because the virtio-gpu device "vdev-&gt;dev" doesn't really have DMA OPS
assigned to it, but parent (virtio-pci or virtio-mmio) device
"vdev-&gt;dev.parent" has. The more, the sgtable in question the code is
trying to sync here was mapped for the parent device (by using its DMA OPS)
previously at:
virtio_gpu_object_shmem_init()-&gt;drm_gem_shmem_get_pages_sgt()-&gt;
dma_map_sgtable(), so should be synced here for the same parent device.

Fixes: b5c9ed70d1a9 ("drm/virtio: Improve DMA API usage for shmem BOs")
Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230224153450.526222-1-olekstysh@gmail.com
</content>
</entry>
<entry>
<title>drm/virtio: Spiff out cmd queue/response traces</title>
<updated>2023-01-02T14:51:27+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-11-30T00:08:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2591939e881cf728b6ac45971eeec2f58051c101'/>
<id>urn:sha1:2591939e881cf728b6ac45971eeec2f58051c101</id>
<content type='text'>
Add a sequence # for more easily matching up cmd/resp, and the # of free
slots in the virtqueue to more easily see starvation issues.

v2: Fix handling of string fields as well

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221130000841.318037-1-robdclark@gmail.com
</content>
</entry>
<entry>
<title>drm/virtio: Return proper error codes instead of -1</title>
<updated>2022-07-19T12:40:58+00:00</updated>
<author>
<name>Dmitry Osipenko</name>
<email>dmitry.osipenko@collabora.com</email>
</author>
<published>2022-06-30T20:07:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4c703f5d6f776eaa6a98611c9b5dfe800fbeb0c8'/>
<id>urn:sha1:4c703f5d6f776eaa6a98611c9b5dfe800fbeb0c8</id>
<content type='text'>
Don't return -1 in error cases, return proper error code. The returned
error codes propagate to error messages and to userspace and it's always
good to have a meaningful error number for debugging purposes.

Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-10-dmitry.osipenko@collabora.com
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/virtio: Improve DMA API usage for shmem BOs</title>
<updated>2022-07-19T12:40:58+00:00</updated>
<author>
<name>Dmitry Osipenko</name>
<email>dmitry.osipenko@collabora.com</email>
</author>
<published>2022-06-30T20:07:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b5c9ed70d1a94c59dad7b1ecfc928863c0fe6ac0'/>
<id>urn:sha1:b5c9ed70d1a94c59dad7b1ecfc928863c0fe6ac0</id>
<content type='text'>
DRM API requires the DRM's driver to be backed with the device that can
be used for generic DMA operations. The VirtIO-GPU device can't perform
DMA operations if it uses PCI transport because PCI device driver creates
a virtual VirtIO-GPU device that isn't associated with the PCI. Use PCI's
GPU device for the DRM's device instead of the VirtIO-GPU device and drop
DMA-related hacks from the VirtIO-GPU driver.

Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-8-dmitry.osipenko@collabora.com
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/virtio: Check whether transferred 2D BO is shmem</title>
<updated>2022-07-19T12:40:57+00:00</updated>
<author>
<name>Dmitry Osipenko</name>
<email>dmitry.osipenko@collabora.com</email>
</author>
<published>2022-06-30T20:07:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e473216b42aa1fd9fc6b94b608b42c210c655908'/>
<id>urn:sha1:e473216b42aa1fd9fc6b94b608b42c210c655908</id>
<content type='text'>
Transferred 2D BO always must be a shmem BO. Add check for that to prevent
NULL dereference if userspace passes a VRAM BO.

Cc: stable@vger.kernel.org
Reviewed-by: Emil Velikov &lt;emil.l.velikov@gmail.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-3-dmitry.osipenko@collabora.com
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
</content>
</entry>
</feed>
