Hi DRM maintainers,
I’m seeing a userspace-triggerable WARN in idr_alloc() through DRM_IOCTL_GEM_CHANGE_HANDLE. Kernel tree: upstream HEAD: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449 uname: Linux syzkaller 6.18.0 #9 SMP PREEMPT_DYNAMIC Jan Dec 29 10:49:29 CST 2025 x86_64 GNU/Linux Repro / artifacts: C repro: https://github.com/Wmingyu/Crashes/blob/main/b792dc447b8fd1b6a9362756860d25c2de5f8a45/repro.c dmesg: https://github.com/Wmingyu/Crashes/blob/main/b792dc447b8fd1b6a9362756860d25c2de5f8a45/dmesg.txt .config: https://github.com/Wmingyu/Crashes/blob/main/6.18.config What happens:DRM_IOCTL_GEM_CHANGE_HANDLE with new_handle = 0x80000000 reliably triggers: WARNING at lib/idr.c:84 in idr_alloc() call trace includes drm_gem_change_handle_ioctl() Changing only new_handle to 0x7fffffff does NOT trigger the WARN. Expected:Invalid/unsupported new_handle should be rejected (e.g. -EINVAL) without WARN. Dmesg excerpt: [ 1907.563855] WARNING: CPU: 1 PID: 301 at lib/idr.c:84 idr_alloc+0x123/0x140 [ 1907.566607] Modules linked in: bochs drm_shmem_helper drm_kms_helper drm virtio_pci i2c_piix4 ata_generic virtio_pci_legacy_dev i2c_smbus intel_qep drm_panel_orientation_quirks virtio_pci_modern_dev pata_acpi [ 1907.571667] CPU: 1 UID: 0 PID: 301 Comm: repro Not tainted 6.18.0 #9 PREEMPT(voluntary) [ 1907.575671] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 1907.579444] RIP: 0010+0x123/0x140 [ 1907.611616] Call Trace: [ 1907.618510] drm_gem_change_handle_ioctl+0x2bf/0x4f0 [drm] [ 1907.628638] drm_ioctl_kernel+0x1f2/0x3e0 [drm] [ 1907.635531] drm_ioctl+0x580/0xb70 [drm] [ 1907.649467] __x64_sys_ioctl+0x194/0x210 [ 1907.650951] do_syscall_64+0xc6/0x390 [ 1907.652135] entry_SYSCALL_64_after_hwframe+0x77/0x7f Notes: new_handle is u32 in UAPI, but values with bit31 set (>= 0x80000000) seem to reach idr_alloc() with signed-int semantics and trigger this WARN (idr_alloc() typically warns on negative start/invalid range). It would be preferable to fail the ioctl cleanly without warning. If this is already fixed upstream, I’m happy to retest. Thanks, Mingyu Wang
