[PATCH] fbcon: fix null-ptr-deref in fbcon_switch
Add check for vc_cons[logo_shown].d, as it can be released by
vt_ioctl(VT_DISALLOCATE).
Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang
---
drivers/video/fbdev/core/fbcon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index bb6ae995c2e5..7ee0f7b55829 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2254,7 +2254,7 @@ static int fbcon_switch(struct vc_data *vc)
fbcon_update_softback(vc);
}
- if (logo_shown >= 0) {
+ if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
struct vc_data *conp2 = vc_cons[logo_shown].d;
if (conp2->vc_top == logo_lines
@@ -2852,7 +2852,7 @@ static void fbcon_scrolldelta(struct vc_data *vc, int
lines)
return;
if (vc->vc_mode != KD_TEXT || !lines)
return;
- if (logo_shown >= 0) {
+ if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
struct vc_data *conp2 = vc_cons[logo_shown].d;
if (conp2->vc_top == logo_lines
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: fix null-ptr-deref in fbcon_switch
On Sun, Mar 29, 2020 at 12:31 AM Daniel Vetter wrote:
>
> On Sat, Mar 28, 2020 at 4:15 PM Qiujun Huang wrote:
> > Add check for vc_cons[logo_shown].d, as it can be released by
> > vt_ioctl(VT_DISALLOCATE).
>
> Can you pls link to the syzbot report and distill the essence of the
> crash/issue here in the commit message? As-is a bit unclear what's
> going on. Patch itself looks correct.
https://lkml.org/lkml/2020/3/27/403
Thanks.
>
> Thanks, Daniel
>
> > Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com
> > Signed-off-by: Qiujun Huang
> > ---
> > drivers/video/fbdev/core/fbcon.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index bb6ae995c2e5..7ee0f7b55829 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2254,7 +2254,7 @@ static int fbcon_switch(struct vc_data *vc)
> > fbcon_update_softback(vc);
> > }
> >
> > - if (logo_shown >= 0) {
> > + if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
> > struct vc_data *conp2 = vc_cons[logo_shown].d;
> >
> > if (conp2->vc_top == logo_lines
> > @@ -2852,7 +2852,7 @@ static void fbcon_scrolldelta(struct vc_data *vc, int
> > lines)
> > return;
> > if (vc->vc_mode != KD_TEXT || !lines)
> > return;
> > - if (logo_shown >= 0) {
> > + if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
> > struct vc_data *conp2 = vc_cons[logo_shown].d;
> >
> > if (conp2->vc_top == logo_lines
> > --
> > 2.17.1
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] fbcon: fix null-ptr-deref in fbcon_switch
Set logo_shown to FBCON_LOGO_CANSHOW when the vc was deallocated. syzkaller report: https://lkml.org/lkml/2020/3/27/403 general protection fault, probably for non-canonical address 0xdc6c: [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0360-0x0367] RIP: 0010:fbcon_switch+0x28f/0x1740 drivers/video/fbdev/core/fbcon.c:2260 Call Trace: redraw_screen+0x2a8/0x770 drivers/tty/vt/vt.c:1008 vc_do_resize+0xfe7/0x1360 drivers/tty/vt/vt.c:1295 fbcon_init+0x1221/0x1ab0 drivers/video/fbdev/core/fbcon.c:1219 visual_init+0x305/0x5c0 drivers/tty/vt/vt.c:1062 do_bind_con_driver+0x536/0x890 drivers/tty/vt/vt.c:3542 do_take_over_console+0x453/0x5b0 drivers/tty/vt/vt.c:4122 do_fbcon_takeover+0x10b/0x210 drivers/video/fbdev/core/fbcon.c:588 fbcon_fb_registered+0x26b/0x340 drivers/video/fbdev/core/fbcon.c:3259 do_register_framebuffer drivers/video/fbdev/core/fbmem.c:1664 [inline] register_framebuffer+0x56e/0x980 drivers/video/fbdev/core/fbmem.c:1832 dlfb_usb_probe.cold+0x1743/0x1ba3 drivers/video/fbdev/udlfb.c:1735 usb_probe_interface+0x310/0x800 drivers/usb/core/driver.c:374 accessing vc_cons[logo_shown].d->vc_top causes the bug. Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang --- drivers/video/fbdev/core/fbcon.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index bb6ae995c2e5..5eb3fc90f9f6 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -1283,6 +1283,9 @@ static void fbcon_deinit(struct vc_data *vc) if (!con_is_bound(_con)) fbcon_exit(); + if (vc->vc_num == logo_shown) + logo_shown = FBCON_LOGO_CANSHOW; + return; } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: fix null-ptr-deref in fbcon_switch
On Sun, Mar 29, 2020 at 2:13 AM Sam Ravnborg wrote:
>
> Hi Qiujun
>
> Thanks for looking into the sysbot bugs.
>
> On Sat, Mar 28, 2020 at 11:15:10PM +0800, Qiujun Huang wrote:
> > Add check for vc_cons[logo_shown].d, as it can be released by
> > vt_ioctl(VT_DISALLOCATE).
> >
> > Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com
> > Signed-off-by: Qiujun Huang
> > ---
> > drivers/video/fbdev/core/fbcon.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index bb6ae995c2e5..7ee0f7b55829 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2254,7 +2254,7 @@ static int fbcon_switch(struct vc_data *vc)
> > fbcon_update_softback(vc);
> > }
> >
> > - if (logo_shown >= 0) {
> > + if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
> > struct vc_data *conp2 = vc_cons[logo_shown].d;
> >
> > if (conp2->vc_top == logo_lines
> > @@ -2852,7 +2852,7 @@ static void fbcon_scrolldelta(struct vc_data *vc, int
> > lines)
> > return;
> > if (vc->vc_mode != KD_TEXT || !lines)
> > return;
> > - if (logo_shown >= 0) {
> > + if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
> > struct vc_data *conp2 = vc_cons[logo_shown].d;
> >
> > if (conp2->vc_top == logo_lines
>
> I am not familiar with this code.
>
> But it looks like you try to avoid the sympton
> which is that logo_shown has a wrong value after a
> vc is deallocated, and do not fix the root cause.
>
> We have:
>
> vt_ioctl(VT_DISALLOCATE)
> |
> +- vc_deallocate()
> |
> +- visual_deinit()
> |
> +- vc->vc_sw->con_deinit(vc)
> |
> +- fbcon_deinit()
>
> Would it be better to update logo_shown
> in fbcon_deinit()?
> Then we will not try to do anything with
> the logo in fbcon_switch().
>
> fbcon_deinit() is called with console locked
> so there should not be any races.
Get that, thanks.
>
> I did not stare long enough on the code to come up with a patch,
> but this may be a better way to fix it.
>
> Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm/lease: fix potential race in fill_object_idr
On Wed, Mar 18, 2020 at 3:34 PM Daniel Vetter wrote: > > On Tue, Mar 17, 2020 at 11:33 PM Qiujun Huang wrote: > > > > On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter wrote: > > > > > > On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote: > > > > We should hold idr_mutex for idr_alloc. > > > > > > > > Signed-off-by: Qiujun Huang > > > > > > I've not seen the first version of this anywhere in my inbox, not sure > > > where that got lost. > > > > > > Anyway, this seems like a false positive - I'm assuming this was caught > > > with KCSAN. The commit message really should mention that. > > > > > > fill_object_idr creates the idr, which yes is only access later on under > > > the idr_mutex. But here it's not yet visible to any other thread, and > > > hence lockless access is safe and correct. > > > > Agree that. > > Do you know what the recommended annotation for kcsan false positives > like this should be? Adding kcsan author Marco. Actually it's not reported by kcsan. I found idr_alloc isn't safe for parallel modifications, and I didn't understand it's a exclusive path here. :) > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in idr_destroy
#syz test: https://github.com/hqj/hqjagain_test.git idr_destroy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/lease: fix WARNING in idr_destroy
drm_lease_create takes ownership of leases. And leases will be released
by drm_master_put.
drm_master_put
->drm_master_destroy
->idr_destroy
So we needn't call idr_destroy again.
Reported-and-tested-by: syzbot+05835159fe322770f...@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang
---
drivers/gpu/drm/drm_lease.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index b481caf..825abe3 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -542,10 +542,12 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
}
DRM_DEBUG_LEASE("Creating lease\n");
+ /* lessee will take the ownership of leases */
lessee = drm_lease_create(lessor, );
if (IS_ERR(lessee)) {
ret = PTR_ERR(lessee);
+ idr_destroy();
goto out_leases;
}
@@ -580,7 +582,6 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
out_leases:
put_unused_fd(fd);
- idr_destroy();
DRM_DEBUG_LEASE("drm_mode_create_lease_ioctl failed: %d\n", ret);
return ret;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm/lease: fix potential race in fill_object_idr
On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter wrote: > > On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote: > > We should hold idr_mutex for idr_alloc. > > > > Signed-off-by: Qiujun Huang > > I've not seen the first version of this anywhere in my inbox, not sure > where that got lost. > > Anyway, this seems like a false positive - I'm assuming this was caught > with KCSAN. The commit message really should mention that. > > fill_object_idr creates the idr, which yes is only access later on under > the idr_mutex. But here it's not yet visible to any other thread, and > hence lockless access is safe and correct. Agree that. Thanks. > > No idea what the KCSAN complains about safe access like this best practice > is. > -Daniel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/lease: fix WARNING in idr_destroy
On Wed, Mar 18, 2020 at 12:57 AM Daniel Vetter wrote:
>
> On Mon, Mar 16, 2020 at 11:36:08AM +0800, Qiujun Huang wrote:
> > leases has been destroyed:
> > drm_master_put
> > ->drm_master_destroy
> > ->idr_destroy
> >
> > so the "out_lessee" needn't to call idr_destroy again.
> >
> > Reported-and-tested-by:
> > syzbot+05835159fe322770f...@syzkaller.appspotmail.com
> > Signed-off-by: Qiujun Huang
> > ---
> > drivers/gpu/drm/drm_lease.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> > index b481caf..54506c2 100644
> > --- a/drivers/gpu/drm/drm_lease.c
> > +++ b/drivers/gpu/drm/drm_lease.c
> > @@ -577,11 +577,14 @@ int drm_mode_create_lease_ioctl(struct drm_device
> > *dev,
> >
> > out_lessee:
> > drm_master_put();
> > + goto err_exit;
>
> I think this is correct, but also confusioning and inconsistent with the
> existing style. Most error cases before drm_lease_create explicit destroy
> the idr, except the one for drm_lease_create.
Yeah, it is.
>
> Instead of your patch I'd
> - remove the idr_destry from the error unrolling here
> - add it the to drm_lease_create error case
> - add a comment above the call to drm_lease_crete that it takes ownership
> of the lease idr
>
> Can you pls respin and retest to make sure that patch is still correct?
I get that, thanks.
>
> Thanks, Daniel
>
> >
> > out_leases:
> > - put_unused_fd(fd);
> > idr_destroy();
> >
> > +err_exit:
> > + put_unused_fd(fd);
> > +
> > DRM_DEBUG_LEASE("drm_mode_create_lease_ioctl failed: %d\n", ret);
> > return ret;
> > }
> > --
> > 1.8.3.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/powerplay: remove redundant check in smu_set_soft_freq_range
min(max) is type of uint32_t, min < 0(max < 0) is never true.
move it.
Addressed-Coverity: ("Unsigned compared against 0")
Signed-off-by: Qiujun Huang
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index 96e81c7bc266..fdaea0cc2828 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -222,9 +222,6 @@ int smu_set_soft_freq_range(struct smu_context *smu, enum
smu_clk_type clk_type,
{
int ret = 0;
- if (min < 0 && max < 0)
- return -EINVAL;
-
if (!smu_clk_dpm_is_enabled(smu, clk_type))
return 0;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] drm/lease: fix potential race in fill_object_idr
We should hold idr_mutex for idr_alloc.
Signed-off-by: Qiujun Huang
---
drivers/gpu/drm/drm_lease.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index b481caf..427ee21 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -418,6 +418,7 @@ static int fill_object_idr(struct drm_device *dev,
goto out_free_objects;
}
+ mutex_lock(>mode_config.idr_mutex);
/* add their IDs to the lease request - taking into account
universal planes */
for (o = 0; o < object_count; o++) {
@@ -437,7 +438,7 @@ static int fill_object_idr(struct drm_device *dev,
if (ret < 0) {
DRM_DEBUG_LEASE("Object %d cannot be inserted into
leases (%d)\n",
object_id, ret);
- goto out_free_objects;
+ goto out_unlock;
}
if (obj->type == DRM_MODE_OBJECT_CRTC && !universal_planes) {
struct drm_crtc *crtc = obj_to_crtc(obj);
@@ -445,20 +446,22 @@ static int fill_object_idr(struct drm_device *dev,
if (ret < 0) {
DRM_DEBUG_LEASE("Object primary plane %d cannot
be inserted into leases (%d)\n",
object_id, ret);
- goto out_free_objects;
+ goto out_unlock;
}
if (crtc->cursor) {
ret = idr_alloc(leases, _lease_idr_object,
crtc->cursor->base.id, crtc->cursor->base.id + 1, GFP_KERNEL);
if (ret < 0) {
DRM_DEBUG_LEASE("Object cursor plane %d
cannot be inserted into leases (%d)\n",
object_id, ret);
- goto out_free_objects;
+ goto out_unlock;
}
}
}
}
ret = 0;
+out_unlock:
+ mutex_unlock(>mode_config.idr_mutex);
out_free_objects:
for (o = 0; o < object_count; o++) {
if (objects[o])
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/lease: fix WARNING in idr_destroy
leases has been destroyed:
drm_master_put
->drm_master_destroy
->idr_destroy
so the "out_lessee" needn't to call idr_destroy again.
Reported-and-tested-by: syzbot+05835159fe322770f...@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang
---
drivers/gpu/drm/drm_lease.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index b481caf..54506c2 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -577,11 +577,14 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
out_lessee:
drm_master_put();
+ goto err_exit;
out_leases:
- put_unused_fd(fd);
idr_destroy();
+err_exit:
+ put_unused_fd(fd);
+
DRM_DEBUG_LEASE("drm_mode_create_lease_ioctl failed: %d\n", ret);
return ret;
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in idr_destroy
We need to get idr_mutex first for idr_alloc.
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index b481cafdde28..aa72c8344ec7 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -420,6 +420,7 @@ static int fill_object_idr(struct drm_device *dev,
/* add their IDs to the lease request - taking into account
universal planes */
+ mutex_lock(>mode_config.idr_mutex);
for (o = 0; o < object_count; o++) {
struct drm_mode_object *obj = objects[o];
u32 object_id = objects[o]->id;
@@ -457,6 +458,7 @@ static int fill_object_idr(struct drm_device *dev,
}
}
}
+ mutex_unlock(>mode_config.idr_mutex);
ret = 0;
out_free_objects:
On Tue, Mar 3, 2020 at 3:50 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10e978e3e0
> kernel config: https://syzkaller.appspot.com/x/.config?x=5d2e033af114153f
> dashboard link: https://syzkaller.appspot.com/bug?extid=05835159fe322770fe3d
> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/
> c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14e978e3e0
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10b1a819e0
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+05835159fe322770f...@syzkaller.appspotmail.com
>
> R10: R11: 0246 R12: 006dbc2c
> R13: 7fc6b3362d90 R14: 0004 R15: 002d
> [ cut here ]
> WARNING: CPU: 0 PID: 12260 at lib/radix-tree.c:682 radix_tree_free_nodes
> lib/radix-tree.c:682 [inline]
> WARNING: CPU: 0 PID: 12260 at lib/radix-tree.c:682 idr_destroy+0x1ae/0x260
> lib/radix-tree.c:1572
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 0 PID: 12260 Comm: syz-executor386 Not tainted 5.6.0-rc3-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1fb/0x318 lib/dump_stack.c:118
> panic+0x264/0x7a9 kernel/panic.c:221
> __warn+0x209/0x210 kernel/panic.c:582
> report_bug+0x1b6/0x2f0 lib/bug.c:195
> fixup_bug arch/x86/kernel/traps.c:174 [inline]
> do_error_trap+0xcf/0x1c0 arch/x86/kernel/traps.c:267
> do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:286
> invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
> RIP: 0010:radix_tree_free_nodes lib/radix-tree.c:682 [inline]
> RIP: 0010:idr_destroy+0x1ae/0x260 lib/radix-tree.c:1572
> Code: b5 63 f9 48 89 df 48 c7 c6 c0 0a 13 88 e8 6a ce 50 f9 4c 3b 65 b8 74 57
> e8 cf b5 63 f9 4d 89 fc e9 67 ff ff ff e8 c2 b5 63 f9 <0f> 0b eb d5 89 f9 80
> e1 07 38 c1 7c 84 e8 c0 de a0 f9 e9 7a ff ff
> RSP: 0018:c90005107ba0 EFLAGS: 00010293
> RAX: 881363be RBX: 888087dba998 RCX: 888094062300
> RDX: RSI: 0040 RDI: 888087dba988
> RBP: c90005107be8 R08: 88136330 R09: ed1012a78181
> R10: ed1012a78181 R11: R12: 888087dba980
> R13: R14: dc00 R15:
> drm_mode_create_lease_ioctl+0x1347/0x1860 drivers/gpu/drm/drm_lease.c:583
> drm_ioctl_kernel+0x2cf/0x410 drivers/gpu/drm/drm_ioctl.c:786
> drm_ioctl+0x52f/0x890 drivers/gpu/drm/drm_ioctl.c:886
> vfs_ioctl fs/ioctl.c:47 [inline]
> ksys_ioctl fs/ioctl.c:763 [inline]
> __do_sys_ioctl fs/ioctl.c:772 [inline]
> __se_sys_ioctl+0x113/0x190 fs/ioctl.c:770
> __x64_sys_ioctl+0x7b/0x90 fs/ioctl.c:770
> do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x44a4b9
> Code: e8 0c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 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 0f
> 83 9b cc fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:7fc6b3362d88 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 006dbc28 RCX: 0044a4b9
> RDX: 2040 RSI: ffc6 RDI: 0003
> RBP: 006dbc20 R08: 0001 R09: 0039
> R10: R11: 0246 R12: 006dbc2c
> R13: 7fc6b3362d90 R14: 0004 R15: 002d
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug 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 syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this bug, for details
