[PATCH RFC] drm/lease: Fix warning on large user-controlled allocations

0 views
Skip to first unread message

syzbot

unread,
May 13, 2026, 6:26:42 PM (2 days ago) May 13
to syzkaller-upst...@googlegroups.com, syz...@lists.linux.dev
In drm_mode_create_lease_ioctl(), a user-provided object_count is used
to allocate memory for object_ids and objects. When a user requests a
massive number of objects, the allocation size can exceed the maximum
contiguous physical memory limit (MAX_PAGE_ORDER). Since kzalloc_objs()
defaults to GFP_KERNEL without __GFP_NOWARN, this triggers a
WARN_ON_ONCE_GFP in the page allocator.

To fix this, replace kzalloc_objs() with kvzalloc_objs() in
fill_object_idr() and memdup_array_user() with vmemdup_array_user() in
drm_mode_create_lease_ioctl(). This allows the allocations to gracefully
fall back to virtually contiguous memory (vmalloc) if the requested size
is too large or physical memory is fragmented, preventing the warning
and allowing large lease requests to succeed or fail gracefully with
-ENOMEM. Update the corresponding kfree() calls to kvfree() accordingly.

Fixes: 62884cd386b876638720ef88374b31a84ca7ee5f ("drm: Add four ioctls for managing drm mode object leases [v7]")
Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview
Reported-by: syzbot+03fb58...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=03fb58296859d8dbab4d
Link: https://syzkaller.appspot.com/ai_job?id=d9152b5a-380f-4c4e-af5b-1890078e5d46
To: <air...@gmail.com>
To: <dri-...@lists.freedesktop.org>
To: <maarten....@linux.intel.com>
To: <mri...@kernel.org>
To: <sim...@ffwll.ch>
To: <tzimm...@suse.de>
Cc: <linux-...@vger.kernel.org>

---
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 5d2cf724c..9ccfa4712 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -386,7 +386,7 @@ static int fill_object_idr(struct drm_device *dev,
int ret;
bool universal_planes = READ_ONCE(lessor_priv->universal_planes);

- objects = kzalloc_objs(struct drm_mode_object *, object_count);
+ objects = kvzalloc_objs(struct drm_mode_object *, object_count);
if (!objects)
return -ENOMEM;

@@ -462,7 +462,7 @@ static int fill_object_idr(struct drm_device *dev,
if (objects[o])
drm_mode_object_put(objects[o]);
}
- kfree(objects);
+ kvfree(objects);
return ret;
}

@@ -509,8 +509,8 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
/* Handle leased objects, if any */
idr_init(&leases);
if (object_count != 0) {
- object_ids = memdup_array_user(u64_to_user_ptr(cl->object_ids),
- object_count, sizeof(__u32));
+ object_ids = vmemdup_array_user(u64_to_user_ptr(cl->object_ids),
+ object_count, sizeof(__u32));
if (IS_ERR(object_ids)) {
ret = PTR_ERR(object_ids);
idr_destroy(&leases);
@@ -520,7 +520,7 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
/* fill and validate the object idr */
ret = fill_object_idr(dev, lessor_priv, &leases,
object_count, object_ids);
- kfree(object_ids);
+ kvfree(object_ids);
if (ret) {
drm_dbg_lease(dev, "lease object lookup failed: %i\n", ret);
idr_destroy(&leases);


base-commit: 5d6919055dec134de3c40167a490f33c74c12581
--
This is an AI-generated patch subject to moderation.
Reply with '#syz upstream' to send it to the mailing list.
Reply with '#syz reject' to reject it.

See for more information.

Aleksandr Nogikh

unread,
May 15, 2026, 5:41:54 AM (20 hours ago) May 15
to syzbot, syzkaller-upst...@googlegroups.com, syz...@lists.linux.dev
Ok. Let's experiment with "upstreaming" it.
#syz upstream

On Thu, May 14, 2026 at 12:26 AM 'syzbot' via
syzkaller-upstream-moderation
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-upstream-moderation" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-upstream-m...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-upstream-moderation/9cbc091e-97f8-41a3-97eb-c1f2137ccc53%40mail.kernel.org.

syzbot ci

unread,
May 15, 2026, 5:44:17 AM (20 hours ago) May 15
to nog...@google.com, nog...@google.com, syz...@kernel.org, syz...@lists.linux.dev, syzkaller-upst...@googlegroups.com
> Ok. Let's experiment with "upstreaming" it.
> #syz upstream

Failed to process the command. Contact syzk...@googlegroups.com.

syzbot

unread,
May 15, 2026, 5:45:37 AM (20 hours ago) May 15
to syzkaller-upstrea...@googlegroups.com, syz...@lists.linux.dev
In drm_mode_create_lease_ioctl(), a user-provided object_count is used
to allocate memory for object_ids and objects. When a user requests a
massive number of objects, the allocation size can exceed the maximum
contiguous physical memory limit (MAX_PAGE_ORDER). Since kzalloc_objs()
defaults to GFP_KERNEL without __GFP_NOWARN, this triggers a
WARN_ON_ONCE_GFP in the page allocator.

To fix this, replace kzalloc_objs() with kvzalloc_objs() in
fill_object_idr() and memdup_array_user() with vmemdup_array_user() in
drm_mode_create_lease_ioctl(). This allows the allocations to gracefully
fall back to virtually contiguous memory (vmalloc) if the requested size
is too large or physical memory is fragmented, preventing the warning
and allowing large lease requests to succeed or fail gracefully with
-ENOMEM. Update the corresponding kfree() calls to kvfree() accordingly.

Fixes: 62884cd386b876638720ef88374b31a84ca7ee5f ("drm: Add four ioctls for managing drm mode object leases [v7]")
Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview
Reported-by: syzbot+03fb58...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=03fb58296859d8dbab4d
Link: https://syzkaller.appspot.com/ai_job?id=d9152b5a-380f-4c4e-af5b-1890078e5d46
Signed-off-by: Aleksandr Nogikh <nog...@google.com>
See for more information.

syzbot ci

unread,
May 15, 2026, 12:06:20 PM (13 hours ago) May 15
to nog...@google.com, nog...@google.com, syz...@kernel.org, syz...@lists.linux.dev, syzkaller-upst...@googlegroups.com
> Ok. Let's experiment with "upstreaming" it.
> #syz upstream

Failed to process the command. Contact syzk...@googlegroups.com.

>

syzbot ci

unread,
May 15, 2026, 3:48:41 PM (10 hours ago) May 15
to nog...@google.com, nog...@google.com, syz...@kernel.org, syz...@lists.linux.dev, syzkaller-upst...@googlegroups.com
> Ok. Let's experiment with "upstreaming" it.
> #syz upstream

Failed to process the command. Contact syzk...@googlegroups.com.

>
Reply all
Reply to author
Forward
0 new messages