Message-ID: <f615f704-11b9-4185-a19d-ee9f253aca9d@suse.de>
Date: Fri, 6 Feb 2026 12:23:37 +0100
From: Thomas Zimmermann <tzimmermann@...e.de>
To: 王志 <23009200614@....xidian.edu.cn>, mripard@...nel.org,
 maarten.lankhorst@...ux.intel.com
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] WARNING in drm_gem_object_handle_put_unlocked during
 drm_release on Linux 6.18

Hi

Am 06.02.26 um 12:18 schrieb 王志:
> Hi,
>
> Just a gentle follow-up on this bug report. Since it's been about three weeks, we wanted to check the status and see if this is something you’d like us to pursue further.
>
> We don’t want to let this slip if it’s a valid issue, but we also understand if it’s not a priority. Could you let us know if we should provide more data (like the QEMU DRM model or a further reduced reproducer), or if we can close this on our end?
>
> Thanks for your time!

Honestly speaking, no one will look at these bug reports if they require 
your customization to qemu. If the bug doesn't happen with the upstream 
code, then it's not a problem of upstream.

Best regards
Thomas

>
>
>> -----原始邮件-----
>> 发件人: 王志 <23009200614@....xidian.edu.cn>
>> 发送时间:2026-01-16 23:33:04 (星期五)
>> 收件人: "Thomas Zimmermann" <tzimmermann@...e.de>
>> 主题: Re: Re: [BUG] WARNING in drm_gem_object_handle_put_unlocked during drm_release on Linux 6.18
>>
>> Hi,
>>
>> thank you very much for testing the reproducer and for the detailed feedback.
>>
>>> -----原始邮件-----
>>> 发件人: "Thomas Zimmermann" <tzimmermann@...e.de>
>>> 发送时间:2026-01-16 17:38:57 (星期五)
>>> 收件人: 王志 <23009200614@....xidian.edu.cn>, "Maarten Lankhorst" <maarten.lankhorst@...ux.intel.com>, "Maxime Ripard" <mripard@...nel.org>
>>> 主题: Re: [BUG] WARNING in drm_gem_object_handle_put_unlocked during drm_release on Linux 6.18
>>>
>>> Hi
>>>
>>> Am 16.01.26 um 09:44 schrieb 王志:
>>>> Dear Maintainers,
>>>>
>>>> I hope you are doing well. I am following up on the DRM warning in drm_gem_object_handle_put_unlocked that I reported on January 10. I wanted to check whether there has been any progress in investigating this issue.
>>>>
>>>> If you encounter any difficulties reproducing the bug or need additional reproducer tests, logs, or QEMU device modeling files, we would be happy to provide assistance.
>>> I'm running the reproducer in a qemu guest with bochs. There's no error
>>> so far. Do I need any special parameter?
>>>
>> This issue depends on a custom DRM device model that we added to QEMU, so it will not reproduce on a vanilla QEMU setup with only bochs or virtio-gpu enabled. To reproduce the warning, the following steps are required:
>>
>> 1. Build QEMU with our provided device model
>> Please first build QEMU with the DRM device modeling code we provided (the custom PCI device).
>>
>> 2. Start QEMU with the custom DRM device enabled
>> In the QEMU command line, add the device:
>> -device bochs_drm_pci
>>
>> 3. Verify the device inside the guest
>> After booting the guest, please check:
>> ls /dev/dri
>> On our setup, the custom device appears as card2.
>>
>> Adjust the reproducer if needed
>> If card2 does not appear and the device is enumerated with a different index (for example card0), please update the reproducer accordingly.
>>
>> In the reproducer, at around line 300:
>> res = syz_open_dev(/*dev=*/0x200000000000, /*id=*/2,
>>                     /*flags=*/0x20001);
>> Please change the id value to match the actual DRM device index present in /dev/dri (e.g. 0 if the device is card0), then rebuild and rerun the reproducer.
>>
>> With the above setup, the WARNING in drm_gem_object_handle_put_unlocked can be triggered reliably. On our machines, this reproduces the issue consistently.
>>
>>>> Thank you very much for your time and support.
>>>>
>>>> Best regards,
>>>> Zhi Wang
>>>>
>>>>
>>>>> -----原始邮件-----
>>>>> 发件人: 王志 <wangzhi_xd@....xidian.edu.cn>
>>>>> 发送时间:2026-01-10 19:25:04 (星期六)
>>>>> 收件人: "Maarten Lankhorst" <maarten.lankhorst@...ux.intel.com>, "Maxime Ripard" <mripard@...nel.org>, "Thomas Zimmermann" <tzimmermann@...e.de>
>>>>> 抄送: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
>>>>> 主题: [BUG] WARNING in drm_gem_object_handle_put_unlocked during drm_release on Linux 6.18
>>>>>
>>>>> Dear Maintainers,
>>>>> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash was triggered.
>>>>> HEAD commit:7d0a66e4bb9081d75c82ec4957c50034cb0ea449
>>>>> git tree: upstream
>>>>> Output:https://github.com/manual0/crash/blob/main/report1.txt
>>> This report says:
>>>
>>> SYZFAIL: failed to recv rpc
>>> fd=3 want=4 recv=0 n=0 (errno 9: Bad file descriptor)
>>>
>>> If the DRM report a result of this problem?
>>>
>>> Best regards
>>> Thomas
>>>
>>>>> Kernel config: https://github.com/manual0/crash/blob/main/config.txt
>>>>> C reproducer:https://github.com/manual0/crash/blob/main/repro1.c
>>>>>
>>>>> drm_gem_object_handle_put_unlocked within drivers/gpu/drm/drm_gem.c which was identified during fuzzing on a Linux 6.18 kernel. This warning indicates a reference counting inconsistency when releasing a GEM object handle during the process exit path.The issue consistently occurs during the resource cleanup sequence where drm_release calls drm_file_free and subsequently drm_gem_release, which then iterates through GEM handles via idr_for_each. We noticed that syzbot has previously reported a similar warning in drm_gem_object_handle_put_unlocked under extid ef3256a360c02207a4cb, but our finding is distinct because the syzbot report is triggered during the creation path via drm_mode_create_dumb_ioctl whereas our trace proves the issue persists in the cleanup path even on the newer 6.18.0 upstream tree. We have searched for existing patches but found none that address this specific release-side inconsistency. This bug was reproduced in a specialized environment using a custom-modeled device added to QEMU to simulate specific hardware-driver interactions. To assist in your analysis, we have provided our QEMU device modeling file in the appendix as the bug may not be triggerable on standard emulated hardware.
>>>>>
>>>>> If you fix this issue, please add the following tag to the commit:
>>>>> Reported-by: Zhi Wang <wangzhi@....xidian.edu.cn>, Bin Yu<byu@...ian.edu.cn>, MingYu Wang<w15303746062@....com>, WenJian Lu<19861702678@....com>, KeFeng Gao<2401553064@...com>, thank you!
>>>>>
>>>>> WARNING: CPU: 1 PID: 108806 at drivers/gpu/drm/drm_gem.c:300 drm_gem_object_handle_put_unlocked+0x30e/0x3e0
>>>>> Modules linked in:
>>>>> CPU: 1 UID: 0 PID: 108806 Comm: syz.1.31978 Not tainted 6.18.0 #1 PREEMPT(full)
>>>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
>>>>> RIP: 0010:drm_gem_object_handle_put_unlocked+0x30e/0x3e0
>>>>> Code: ed 74 61 e8 74 a8 84 fc 4c 89 e7 e8 2c 9e 94 00 48 c7 c1 60 09 ea 8b 4c 89 ea 48 c7 c7 40 05 ea 8b 48 89 c6 e8 e3 3b 44 fc 90 <0f> 0b 90 90 5b 5d 41 5c 41 5d 41 5e 41 5f e9 3f a8 84 fc 4c 89 ff
>>>>> RSP: 0018:ffffc90002d27b80 EFLAGS: 00010286
>>>>> RAX: 0000000000000000 RBX: ffff88811ac0fbe0 RCX: ffffffff8179ed09
>>>>> RDX: ffff888124a2ba00 RSI: ffffffff8179ed16 RDI: 0000000000000001
>>>>> RBP: ffff888107df1000 R08: 0000000000000001 R09: ffffed1026bc4841
>>>>> R10: 0000000000000001 R11: 0000000000139fc0 R12: ffff8881001ec0c8
>>>>> R13: ffff88801c71bd60 R14: 0000000000000000 R15: ffff888107df1004
>>>>> FS:  000055557ced1500(0000) GS:ffff8881a2601000(0000) knlGS:0000000000000000
>>>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>> CR2: 00007ffe5646ff00 CR3: 000000012fba2000 CR4: 00000000000006f0
>>>>> Call Trace:
>>>>>    <TASK>
>>>>>    drm_gem_object_release_handle+0xc7/0x200
>>>>>    idr_for_each+0x119/0x230 home/wmy/Fuzzer/third_tool/linux-6.18/lib/idr.c:208
>>>>>    drm_gem_release+0x29/0x40
>>>>>    drm_file_free.part.0+0x724/0xcf0
>>>>>    drm_close_helper.isra.0+0x183/0x1f0
>>>>>    drm_release+0x1ab/0x360
>>>>>    __fput+0x402/0xb50 home/wmy/Fuzzer/third_tool/linux-6.18/fs/file_table.c:468
>>>>>    task_work_run+0x16b/0x260 home/wmy/Fuzzer/third_tool/linux-6.18/kernel/task_work.c:227
>>>>>    exit_to_user_mode_loop+0xf9/0x130
>>>>>    do_syscall_64+0x424/0xfa0 home/wmy/Fuzzer/third_tool/linux-6.18/arch/x86/entry/syscall_32.c:308
>>>>>    entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>>>> RIP: 0033:0x7f5f9d3b059d
>>>>> Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 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 a8 ff ff ff f7 d8 64 89 01 48
>>>>> RSP: 002b:00007ffeb85fc6d8 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
>>>>> RAX: 0000000000000000 RBX: 00007f5f9d627da0 RCX: 00007f5f9d3b059d
>>>>> RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
>>>>> RBP: 00007ffeb85fc778 R08: 0000001b3292016a R09: 0000000000000000
>>>>> R10: 0000001b32d20000 R11: 0000000000000246 R12: ffffffffffffffff
>>>>> R13: 00007f5f9d62609c R14: 00007f5f9d627da0 R15: 00007ffeb85fc7a0
>>>>>    </TASK>
>>>>>
>>>>> Thanks,
>>>>> Zhi Wang
>>> -- 
>>> --
>>> Thomas Zimmermann
>>> Graphics Driver Developer
>>> SUSE Software Solutions Germany GmbH
>>> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
>>> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
>>>
>>>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)

Powered by blists - more mailing lists