* Re: [syzbot] [dri?] WARNING in drm_mm_takedown
2026-07-29 2:08 [syzbot] [dri?] WARNING in drm_mm_takedown syzbot
@ 2026-08-09 20:57 ` syzbot
2026-11-03 8:23 ` Forwarded: [PATCH v2] drm/virtio: Put GEM objects when dropping a vbuf without queueing it syzbot
1 sibling, 0 replies; 3+ messages in thread
From: syzbot @ 2026-08-09 20:57 UTC (permalink / raw)
To: airlied, dri-devel, linux-kernel, maarten.lankhorst, mripard,
simona, syzkaller-bugs, tzimmermann
syzbot has found a reproducer for the following issue on:
HEAD commit: b643e495ae92 Merge tag 's390-7.2-7' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1531a2c6580000
kernel config: https://syzkaller.appspot.com/x/.config?x=c44651ea7dd2f307
dashboard link: https://syzkaller.appspot.com/bug?extid=d93b9064fe5f74af3aa3
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=138cdfb9580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1373ffb9580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-b643e495.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/9eb4fbda136d/vmlinux-b643e495.xz
kernel image: https://storage.googleapis.com/syzbot-assets/53cbbd75c40a/bzImage-b643e495.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d93b9064fe5f74af3aa3@syzkaller.appspotmail.com
Console: switching to colour dummy device 80x25
------------[ cut here ]------------
Memory manager not clean during takedown.
WARNING: drivers/gpu/drm/drm_mm.c:965 at drm_mm_takedown+0x62/0x280 drivers/gpu/drm/drm_mm.c:965, CPU#0: syz.0.28/5943
Modules linked in:
CPU: 0 UID: 0 PID: 5943 Comm: syz.0.28 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:drm_mm_takedown+0x62/0x280 drivers/gpu/drm/drm_mm.c:965
Code: 8b 43 38 48 39 c5 75 16 e8 3b 0e 45 fc 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e e9 0a 9f f8 05 e8 25 0e 45 fc 48 8d 3d 2e cb 67 0b <67> 48 0f b9 3a 48 c7 c0 e0 13 47 8e 48 ba 00 00 00 00 00 fc ff df
RSP: 0018:ffffc90003aff790 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff88802b8a0c68 RCX: ffffffff85c5509b
RDX: ffff888030942540 RSI: ffffffff85c5655b RDI: ffffffff912d3090
RBP: ffff88802b8a0ca0 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff888029bdb900
R13: ffff888029bdb918 R14: ffffffff85c44260 R15: 0000000000000000
FS: 000055557bc5c500(0000) GS:ffff8880d5dec000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00001c245591d000 CR3: 0000000038e44000 CR4: 0000000000352ef0
Call Trace:
<TASK>
drm_managed_release+0x1bb/0x540 drivers/gpu/drm/drm_managed.c:75
drm_dev_release drivers/gpu/drm/drm_drv.c:914 [inline]
kref_put include/linux/kref.h:65 [inline]
drm_dev_put.part.0+0xca/0x140 drivers/gpu/drm/drm_drv.c:948
drm_dev_put+0x1f/0x30 drivers/gpu/drm/drm_drv.c:947
virtio_dev_remove+0xb8/0x170 drivers/virtio/virtio.c:375
device_remove+0xcb/0x180 drivers/base/dd.c:616
__device_release_driver drivers/base/dd.c:1349 [inline]
device_release_driver_internal+0x44e/0x620 drivers/base/dd.c:1372
bus_remove_device+0x2bc/0x560 drivers/base/bus.c:664
device_del+0x376/0x9b0 drivers/base/core.c:3961
device_unregister+0x1d/0xe0 drivers/base/core.c:4002
unregister_virtio_device+0x39/0x60 drivers/virtio/virtio.c:594
virtio_pci_remove+0x7c/0x110 drivers/virtio/virtio_pci_common.c:758
pci_device_remove+0xb2/0x1d0 drivers/pci/pci-driver.c:512
device_remove+0xcb/0x180 drivers/base/dd.c:616
__device_release_driver drivers/base/dd.c:1349 [inline]
device_release_driver_internal+0x44e/0x620 drivers/base/dd.c:1372
pci_stop_dev drivers/pci/remove.c:27 [inline]
pci_stop_bus_device+0x120/0x160 drivers/pci/remove.c:93
pci_stop_and_remove_bus_device+0x58/0xa0 drivers/pci/remove.c:128
pci_stop_and_remove_bus_device_locked+0x1a/0x20 drivers/pci/remove.c:136
remove_store+0x123/0x140 drivers/pci/pci-sysfs.c:523
dev_attr_store+0x58/0x80 drivers/base/core.c:2505
sysfs_kf_write+0xf2/0x150 fs/sysfs/file.c:145
kernfs_fop_write_iter+0x3e0/0x5f0 fs/kernfs/file.c:345
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x6ac/0x1050 fs/read_write.c:687
ksys_write+0x12a/0x250 fs/read_write.c:739
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa232f9e0d9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd4f8ff7c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fa233225fa0 RCX: 00007fa232f9e0d9
RDX: 0000000000000001 RSI: 00002000000000c0 RDI: 0000000000000003
RBP: 00007fa233035024 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fa233225fac R14: 00007fa233225fa0 R15: 00007fa233225fa0
</TASK>
----------------
Code disassembly (best guess):
0: 8b 43 38 mov 0x38(%rbx),%eax
3: 48 39 c5 cmp %rax,%rbp
6: 75 16 jne 0x1e
8: e8 3b 0e 45 fc call 0xfc450e48
d: 48 83 c4 08 add $0x8,%rsp
11: 5b pop %rbx
12: 5d pop %rbp
13: 41 5c pop %r12
15: 41 5d pop %r13
17: 41 5e pop %r14
19: e9 0a 9f f8 05 jmp 0x5f89f28
1e: e8 25 0e 45 fc call 0xfc450e48
23: 48 8d 3d 2e cb 67 0b lea 0xb67cb2e(%rip),%rdi # 0xb67cb58
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 48 c7 c0 e0 13 47 8e mov $0xffffffff8e4713e0,%rax
36: 48 ba 00 00 00 00 00 movabs $0xdffffc0000000000,%rdx
3d: fc ff df
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Forwarded: [PATCH v2] drm/virtio: Put GEM objects when dropping a vbuf without queueing it
2026-07-29 2:08 [syzbot] [dri?] WARNING in drm_mm_takedown syzbot
2026-08-09 20:57 ` syzbot
@ 2026-11-03 8:23 ` syzbot
1 sibling, 0 replies; 3+ messages in thread
From: syzbot @ 2026-11-03 8:23 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH v2] drm/virtio: Put GEM objects when dropping a vbuf without queueing it
Author: fei.yu@intel.com
From: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
virtio_gpu_queue_ctrl_sgs() drops the command when drm_dev_enter()
fails or when vqs_released is set during device removal. It unlocks the
reservations and frees the vbuf, but never releases the GEM object
references that the caller transferred in vbuf->objs. Those references
are normally dropped by the dequeue worker once the host completes the
command, which never happens for a command that was not queued.
If a framebuffer flush or transfer (e.g. the fbdev damage worker) races
with device removal, the GEM object backing the buffer keeps a stale
reference and is never freed. GEM objects do not hold a reference on the
drm_device, so the device is still released, with the object's node left
in the vma offset manager:
Memory manager not clean during takedown.
WARNING: drivers/gpu/drm/drm_mm.c:965 at drm_mm_takedown+0x62/0x280
Call Trace:
drm_managed_release+0x1bb/0x540 drivers/gpu/drm/drm_managed.c:75
drm_dev_release drivers/gpu/drm/drm_drv.c:924 [inline]
drm_dev_put+0x1f/0x30 drivers/gpu/drm/drm_drv.c:957
virtio_dev_remove+0xb8/0x170 drivers/virtio/virtio.c:375
...
virtio_pci_remove+0x7c/0x110 drivers/virtio/virtio_pci_common.c:760
...
remove_store+0x123/0x140 drivers/pci/pci-sysfs.c:524
The vmalloc_to_sgt() failure path in virtio_gpu_queue_fenced_ctrl_buffer()
has the same problem, and additionally leaks the vbuf itself.
Add a helper that releases a vbuf which was never added to the
virtqueue, including the object references it owns, and use it on all
three early-exit paths. None of the callers touches the object array
after handing it to the queue functions, so this cannot double-put.
Fixes: b1df3a2b24a9 ("drm/virtio: add drm_driver.release callback.")
Fixes: a46991b334f6 ("drm/virtio: abort virtqueue wait on device removal to avoid hung task")
Fixes: e1218b8c0cc1 ("drm/virtio: Use vmalloc for command buffer allocations.")
Reported-by: syzbot+d93b9064fe5f74af3aa3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d93b9064fe5f74af3aa3
Link: https://lore.kernel.org/all/20260927040655.14531-1-ngocthang2710.1999@gmail.com/
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
[fei.yu: also handle the vmalloc_to_sgt() failure path, pass the fence
to the helper instead of a bool, fix the Fixes tags]
Signed-off-by: Fei Yu <fei.yu@intel.com>
---
Testing: syzbot C reproducer (PCI remove/rescan loop) for 120s in QEMU
with fbcon on virtio-gpu: v7.4-rc1 printed "Memory manager not clean
during takedown" in 377 of 441 cycles (kmemleak: 4040 objects); with
this patch, 487 cycles, no warning, no kmemleak report.
v2 (Fei Yu, Nguyen's v1 got no review for weeks):
- also handle the vmalloc_to_sgt() failure path in
virtio_gpu_queue_fenced_ctrl_buffer(), which leaked the vbuf as well
- pass the fence to virtio_gpu_drop_vbuf() instead of a bool
- replace the Fixes tag: b7170f9457f2 only changed the return type;
point at the commits that added the three early-exit paths
v1: https://lore.kernel.org/all/20260927040655.14531-1-ngocthang2710.1999@gmail.com/
Note: Hui Peng's "drm/virtio: fix vbuf->objs double-free, fence NULL
deref, and sgt error path" [1] touches the same paths (by moving the put
into free_vbuf()) and conflicts with this patch.
[1] https://lore.kernel.org/all/20260919223440.3884176-1-benquike@gmail.com/
drivers/gpu/drm/virtio/virtgpu_vq.c | 30 +++++++++++++++++++++--------
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index d99fb9e32..21271966b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -208,6 +208,25 @@ static void free_vbuf(struct virtio_gpu_device *vgdev,
kmem_cache_free(vgdev->vbufs, vbuf);
}
+/*
+ * Free a vbuf that never made it into the virtqueue. The caller handed
+ * over the references in vbuf->objs, which would otherwise have been
+ * dropped by the dequeue worker once the host completed the command, so
+ * release them here. If a fence was passed, the reservations are still
+ * locked and must be unlocked first.
+ */
+static void virtio_gpu_drop_vbuf(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_vbuffer *vbuf,
+ struct virtio_gpu_fence *fence)
+{
+ if (vbuf->objs) {
+ if (fence)
+ virtio_gpu_array_unlock_resv(vbuf->objs);
+ virtio_gpu_array_put_free(vbuf->objs);
+ }
+ free_vbuf(vgdev, vbuf);
+}
+
void virtio_gpu_reclaim_vbufs(struct virtio_gpu_device *vgdev)
{
struct virtio_gpu_vbuffer *vbuf;
@@ -437,9 +456,7 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
int ret, idx;
if (!drm_dev_enter(vgdev->ddev, &idx)) {
- if (fence && vbuf->objs)
- virtio_gpu_array_unlock_resv(vbuf->objs);
- free_vbuf(vgdev, vbuf);
+ virtio_gpu_drop_vbuf(vgdev, vbuf, fence);
return -ENODEV;
}
@@ -459,9 +476,7 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
* synchronize_srcu() wait in drm_dev_unplug().
*/
if (vgdev->vqs_released) {
- if (fence && vbuf->objs)
- virtio_gpu_array_unlock_resv(vbuf->objs);
- free_vbuf(vgdev, vbuf);
+ virtio_gpu_drop_vbuf(vgdev, vbuf, fence);
drm_dev_exit(idx);
return -ENODEV;
}
@@ -542,8 +557,7 @@ static int virtio_gpu_queue_fenced_ctrl_buffer(struct virtio_gpu_device *vgdev,
sgt = vmalloc_to_sgt(vbuf->data_buf, vbuf->data_size,
&sg_ents);
if (!sgt) {
- if (fence && vbuf->objs)
- virtio_gpu_array_unlock_resv(vbuf->objs);
+ virtio_gpu_drop_vbuf(vgdev, vbuf, fence);
return -ENOMEM;
}
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
prerequisite-patch-id: aa41f7089456b709927a2d1d5480fdc2f0f2ec76
prerequisite-patch-id: 78c30e7ee8bc1e8d2c9e0626e8988a021d61b3bc
--
2.43.0
^ permalink raw reply [flat|nested] 3+ messages in thread