[syzbot] [dri?] WARNING in drm_mm_takedown

[syzbot] [dri?] WARNING in drm_mm_takedown

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    62cc90241548 Merge tag 'mm-hotfixes-stable-2026-07-27-14-1..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=121f9632580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=145fa60d73086782
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

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-62cc9024.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b10a9ae7e3d1/vmlinux-62cc9024.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b89124d39495/bzImage-62cc9024.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d93b9064fe5f74af3aa3@syzkaller.appspotmail.com

------------[ 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#3: syz.1.134/6649
Modules linked in:
CPU: 3 UID: 0 PID: 6649 Comm: syz.1.134 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 2b c6 44 fc 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc e8 15 c6 44 fc 48 8d 3d ce 75 68 0b <67> 48 0f b9 3a 48 c7 c0 e0 e3 46 8e 48 ba 00 00 00 00 00 fc ff df
RSP: 0018:ffffc9000383f858 EFLAGS: 00010283
RAX: 0000000000021ab5 RBX: ffff888027c40c68 RCX: ffffc90007884000
RDX: 0000000000080000 RSI: ffffffff85c59a2b RDI: ffffffff912e1000
RBP: ffff888027c40ca0 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880277dbd80
R13: ffff8880277dbd98 R14: ffffffff85c47730 R15: 0000000000000000
FS:  00007fd2ebde36c0(0000) GS:ffff8880d60dc000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa5b75eb580 CR3: 0000000025294000 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
 unbind_store+0xf8/0x110 drivers/base/bus.c:244
 drv_attr_store+0x74/0xb0 drivers/base/bus.c:125
 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:0x7fd2eaf9de99
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:00007fd2ebde3028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fd2eb225fa0 RCX: 00007fd2eaf9de99
RDX: 000000000000000d RSI: 0000200000000280 RDI: 0000000000000008
RBP: 00007fd2eb033eaf R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fd2eb226038 R14: 00007fd2eb225fa0 R15: 00007ffd8ff0ecc8
 </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 2b c6 44 fc       	call   0xfc44c638
   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:	c3                   	ret
  1a:	cc                   	int3
  1b:	cc                   	int3
  1c:	cc                   	int3
  1d:	cc                   	int3
  1e:	e8 15 c6 44 fc       	call   0xfc44c638
  23:	48 8d 3d ce 75 68 0b 	lea    0xb6875ce(%rip),%rdi        # 0xb6875f8
* 2a:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2f:	48 c7 c0 e0 e3 46 8e 	mov    $0xffffffff8e46e3e0,%rax
  36:	48 ba 00 00 00 00 00 	movabs $0xdffffc0000000000,%rdx
  3d:	fc ff df


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [dri?] WARNING in drm_mm_takedown

[syzbot]

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.

Forwarded: [PATCH v2] drm/virtio: Put GEM objects when dropping a vbuf without queueing it

[syzbot]

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