KASAN: use-after-free Read in vgem_gem_dumb_create

34 views
Skip to first unread message

syzbot

unread,
Jan 31, 2020, 5:28:11 PM1/31/20
to air...@linux.ie, alexande...@amd.com, amd...@lists.freedesktop.org, ch...@chris-wilson.co.uk, christia...@amd.com, dan...@ffwll.ch, da...@davemloft.net, dri-...@lists.freedesktop.org, emil.v...@collabora.com, er...@anholt.net, linaro...@lists.linaro.org, linux-...@vger.kernel.org, linux...@vger.kernel.org, net...@vger.kernel.org, robd...@chromium.org, sean...@chromium.org, sumit....@linaro.org, syzkall...@googlegroups.com
Hello,

syzbot found the following crash on:

HEAD commit: 39bed42d Merge tag 'for-linus-hmm' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=179465bee00000
kernel config: https://syzkaller.appspot.com/x/.config?x=2646535f8818ae25
dashboard link: https://syzkaller.appspot.com/bug?extid=0dc4444774d419e916c8
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16251279e00000

The bug was bisected to:

commit 7611750784664db46d0db95631e322aeb263dde7
Author: Alex Deucher <alexande...@amd.com>
Date: Wed Jun 21 16:31:41 2017 +0000

drm/amdgpu: use kernel is_power_of_2 rather than local version

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11628df1e00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=13628df1e00000
console output: https://syzkaller.appspot.com/x/log.txt?x=15628df1e00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0dc444...@syzkaller.appspotmail.com
Fixes: 761175078466 ("drm/amdgpu: use kernel is_power_of_2 rather than local version")

==================================================================
BUG: KASAN: use-after-free in vgem_gem_dumb_create+0x238/0x250 drivers/gpu/drm/vgem/vgem_drv.c:221
Read of size 8 at addr ffff88809fa67908 by task syz-executor.0/14871

CPU: 0 PID: 14871 Comm: syz-executor.0 Not tainted 5.5.0-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+0x197/0x210 lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
__kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:639
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
vgem_gem_dumb_create+0x238/0x250 drivers/gpu/drm/vgem/vgem_drv.c:221
drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94
drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100
drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786
drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0x123/0x180 fs/ioctl.c:747
__do_sys_ioctl fs/ioctl.c:756 [inline]
__se_sys_ioctl fs/ioctl.c:754 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45b349
Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f871af46c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f871af476d4 RCX: 000000000045b349
RDX: 0000000020000180 RSI: 00000000c02064b2 RDI: 0000000000000003
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000285 R14: 00000000004d14d0 R15: 000000000075bf2c

Allocated by task 14871:
save_stack+0x23/0x90 mm/kasan/common.c:72
set_track mm/kasan/common.c:80 [inline]
__kasan_kmalloc mm/kasan/common.c:513 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:486
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:527
kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3551
kmalloc include/linux/slab.h:556 [inline]
kzalloc include/linux/slab.h:670 [inline]
__vgem_gem_create+0x49/0x100 drivers/gpu/drm/vgem/vgem_drv.c:165
vgem_gem_create drivers/gpu/drm/vgem/vgem_drv.c:194 [inline]
vgem_gem_dumb_create+0xd7/0x250 drivers/gpu/drm/vgem/vgem_drv.c:217
drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94
drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100
drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786
drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0x123/0x180 fs/ioctl.c:747
__do_sys_ioctl fs/ioctl.c:756 [inline]
__se_sys_ioctl fs/ioctl.c:754 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 14871:
save_stack+0x23/0x90 mm/kasan/common.c:72
set_track mm/kasan/common.c:80 [inline]
kasan_set_free_info mm/kasan/common.c:335 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:474
kasan_slab_free+0xe/0x10 mm/kasan/common.c:483
__cache_free mm/slab.c:3426 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3757
vgem_gem_free_object+0xbe/0xe0 drivers/gpu/drm/vgem/vgem_drv.c:68
drm_gem_object_free+0x100/0x220 drivers/gpu/drm/drm_gem.c:983
kref_put include/linux/kref.h:65 [inline]
drm_gem_object_put_unlocked drivers/gpu/drm/drm_gem.c:1017 [inline]
drm_gem_object_put_unlocked+0x196/0x1c0 drivers/gpu/drm/drm_gem.c:1002
vgem_gem_create drivers/gpu/drm/vgem/vgem_drv.c:199 [inline]
vgem_gem_dumb_create+0x115/0x250 drivers/gpu/drm/vgem/vgem_drv.c:217
drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94
drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100
drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786
drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0x123/0x180 fs/ioctl.c:747
__do_sys_ioctl fs/ioctl.c:756 [inline]
__se_sys_ioctl fs/ioctl.c:754 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at ffff88809fa67800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 264 bytes inside of
1024-byte region [ffff88809fa67800, ffff88809fa67c00)
The buggy address belongs to the page:
page:ffffea00027e99c0 refcount:1 mapcount:0 mapping:ffff8880aa400c40 index:0x0
raw: 00fffe0000000200 ffffea0002293548 ffffea00023e1f08 ffff8880aa400c40
raw: 0000000000000000 ffff88809fa67000 0000000100000002 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff88809fa67800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88809fa67880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88809fa67900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88809fa67980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88809fa67a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


---
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 syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Hillf Danton

unread,
Jan 31, 2020, 11:32:34 PM1/31/20
to syzbot, air...@linux.ie, alexande...@amd.com, amd...@lists.freedesktop.org, ch...@chris-wilson.co.uk, christia...@amd.com, dan...@ffwll.ch, da...@davemloft.net, dri-...@lists.freedesktop.org, emil.v...@collabora.com, er...@anholt.net, linaro...@lists.linaro.org, linux-...@vger.kernel.org, linux...@vger.kernel.org, net...@vger.kernel.org, robd...@chromium.org, sean...@chromium.org, sumit....@linaro.org, Hillf Danton, syzkall...@googlegroups.com

Fri, 31 Jan 2020 14:28:10 -0800 (PST)
Release obj in error path.

--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -196,10 +196,10 @@ static struct drm_gem_object *vgem_gem_c
return ERR_CAST(obj);

ret = drm_gem_handle_create(file, &obj->base, handle);
- drm_gem_object_put_unlocked(&obj->base);
- if (ret)
+ if (ret) {
+ drm_gem_object_put_unlocked(&obj->base);
return ERR_PTR(ret);
-
+ }
return &obj->base;
}


Dan Carpenter

unread,
Feb 1, 2020, 12:57:00 AM2/1/20
to syzbot, air...@linux.ie, alexande...@amd.com, amd...@lists.freedesktop.org, ch...@chris-wilson.co.uk, christia...@amd.com, dan...@ffwll.ch, da...@davemloft.net, dri-...@lists.freedesktop.org, emil.v...@collabora.com, er...@anholt.net, linaro...@lists.linaro.org, linux-...@vger.kernel.org, linux...@vger.kernel.org, net...@vger.kernel.org, robd...@chromium.org, sean...@chromium.org, sumit....@linaro.org, syzkall...@googlegroups.com
I don't totally understand the stack trace but I do see a double free
bug.

drivers/gpu/drm/vgem/vgem_drv.c
186 static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
187 struct drm_file *file,
188 unsigned int *handle,
189 unsigned long size)
190 {
191 struct drm_vgem_gem_object *obj;
192 int ret;
193
194 obj = __vgem_gem_create(dev, size);

obj->base.handle_count is zero.

195 if (IS_ERR(obj))
196 return ERR_CAST(obj);
197
198 ret = drm_gem_handle_create(file, &obj->base, handle);

We bump it +1 and then the error handling calls
drm_gem_object_handle_put_unlocked(obj);
which calls drm_gem_object_put_unlocked(); which frees obj.


199 drm_gem_object_put_unlocked(&obj->base);

So this is a double free. Could someone check my thinking and send
a patch? It's just a one liner. Otherwise I can send it on Monday.

200 if (ret)
201 return ERR_PTR(ret);
202
203 return &obj->base;
204 }

regards,
dan carpenter

Dan Carpenter

unread,
Feb 1, 2020, 1:18:38 AM2/1/20
to Hillf Danton, syzbot, air...@linux.ie, alexande...@amd.com, amd...@lists.freedesktop.org, ch...@chris-wilson.co.uk, christia...@amd.com, dan...@ffwll.ch, da...@davemloft.net, dri-...@lists.freedesktop.org, emil.v...@collabora.com, er...@anholt.net, linaro...@lists.linaro.org, linux-...@vger.kernel.org, linux...@vger.kernel.org, net...@vger.kernel.org, robd...@chromium.org, sean...@chromium.org, sumit....@linaro.org, syzkall...@googlegroups.com
Oh yeah. It's weird that we never noticed the success path was broken.
It's been that way for three years and no one noticed at all. Very
strange.

Anyway, it already gets freed on error in drm_gem_handle_create() so
we should just delete the drm_gem_object_put_unlocked() here it looks
like.

regards,
dan carpenter

Hillf Danton

unread,
Feb 1, 2020, 4:03:10 AM2/1/20
to Dan Carpenter, syzbot, air...@linux.ie, alexande...@amd.com, amd...@lists.freedesktop.org, ch...@chris-wilson.co.uk, christia...@amd.com, dan...@ffwll.ch, da...@davemloft.net, dri-...@lists.freedesktop.org, emil.v...@collabora.com, er...@anholt.net, linaro...@lists.linaro.org, linux-...@vger.kernel.org, linux...@vger.kernel.org, net...@vger.kernel.org, robd...@chromium.org, sean...@chromium.org, sumit....@linaro.org, syzkall...@googlegroups.com

On Sat, 1 Feb 2020 09:17:57 +0300 Dan Carpenter wrote:
> On Sat, Feb 01, 2020 at 12:32:09PM +0800, Hillf Danton wrote:
> >
> > Release obj in error path.
> >
> > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > @@ -196,10 +196,10 @@ static struct drm_gem_object *vgem_gem_c
> > return ERR_CAST(obj);
> >
> > ret = drm_gem_handle_create(file, &obj->base, handle);
> > - drm_gem_object_put_unlocked(&obj->base);
> > - if (ret)
> > + if (ret) {
> > + drm_gem_object_put_unlocked(&obj->base);
> > return ERR_PTR(ret);
> > -
> > + }
> > return &obj->base;
>
> Oh yeah. It's weird that we never noticed the success path was broken.
> It's been that way for three years and no one noticed at all. Very
> strange.
>
> Anyway, it already gets freed on error in drm_gem_handle_create() so
> we should just delete the drm_gem_object_put_unlocked() here it looks
> like.

Good catch, Dan :P
Would you please post a patch sometime convenient next week?

Thanks
Hillf

Dan Carpenter

unread,
Feb 1, 2020, 11:26:27 AM2/1/20
to Hillf Danton, syzbot, air...@linux.ie, alexande...@amd.com, amd...@lists.freedesktop.org, ch...@chris-wilson.co.uk, christia...@amd.com, dan...@ffwll.ch, da...@davemloft.net, dri-...@lists.freedesktop.org, emil.v...@collabora.com, er...@anholt.net, linaro...@lists.linaro.org, linux-...@vger.kernel.org, linux...@vger.kernel.org, net...@vger.kernel.org, robd...@chromium.org, sean...@chromium.org, sumit....@linaro.org, syzkall...@googlegroups.com
Sure. Will do.

regards,
dan carpenter

syzbot

unread,
Feb 1, 2020, 11:38:13 PM2/1/20
to air...@linux.ie, alexande...@amd.com, amd...@lists.freedesktop.org, ch...@chris-wilson.co.uk, christia...@amd.com, dan.ca...@oracle.com, dan...@ffwll.ch, da...@davemloft.net, dri-...@lists.freedesktop.org, emil.v...@collabora.com, er...@anholt.net, hda...@sina.com, linaro-mm...@lists.linaro.org, linaro...@lists.linaro.org, linux-...@vger.kernel.org, linux...@vger.kernel.org, net...@vger.kernel.org, robd...@chromium.org, sean...@chromium.org, sumit....@linaro.org, syzkall...@googlegroups.com
syzbot has found a reproducer for the following crash on:

HEAD commit: 94f2630b Merge tag '5.6-rc-small-smb3-fix-for-stable' of g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11d6c776e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=99db4e42d047be3
dashboard link: https://syzkaller.appspot.com/bug?extid=0dc4444774d419e916c8
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=152385bee00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=123210a1e00000

The bug was bisected to:

commit 7611750784664db46d0db95631e322aeb263dde7
Author: Alex Deucher <alexande...@amd.com>
Date: Wed Jun 21 16:31:41 2017 +0000

drm/amdgpu: use kernel is_power_of_2 rather than local version

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11628df1e00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=13628df1e00000
console output: https://syzkaller.appspot.com/x/log.txt?x=15628df1e00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0dc444...@syzkaller.appspotmail.com
Fixes: 761175078466 ("drm/amdgpu: use kernel is_power_of_2 rather than local version")

==================================================================
BUG: KASAN: use-after-free in vgem_gem_dumb_create+0x238/0x250 drivers/gpu/drm/vgem/vgem_drv.c:221
Read of size 8 at addr ffff88809a2ee908 by task syz-executor815/10244

CPU: 1 PID: 10244 Comm: syz-executor815 Not tainted 5.5.0-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+0x197/0x210 lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
__kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:641
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
vgem_gem_dumb_create+0x238/0x250 drivers/gpu/drm/vgem/vgem_drv.c:221
drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94
drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100
drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786
drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0x123/0x180 fs/ioctl.c:747
__do_sys_ioctl fs/ioctl.c:756 [inline]
__se_sys_ioctl fs/ioctl.c:754 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x44c3e9
Code: e8 8c e7 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 1b cc fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f40263e9db8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000006ddc58 RCX: 000000000044c3e9
RDX: 0000000020000000 RSI: 00000000c02064b2 RDI: 0000000000000004
RBP: 00000000006ddc50 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006ddc5c
R13: 00007ffed0d4362f R14: 00007f40263ea9c0 R15: 00000000006ddc5c

Allocated by task 10244:
save_stack+0x23/0x90 mm/kasan/common.c:72
set_track mm/kasan/common.c:80 [inline]
__kasan_kmalloc mm/kasan/common.c:515 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:488
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529
kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3551
kmalloc include/linux/slab.h:556 [inline]
kzalloc include/linux/slab.h:670 [inline]
__vgem_gem_create+0x49/0x100 drivers/gpu/drm/vgem/vgem_drv.c:165
vgem_gem_create drivers/gpu/drm/vgem/vgem_drv.c:194 [inline]
vgem_gem_dumb_create+0xd7/0x250 drivers/gpu/drm/vgem/vgem_drv.c:217
drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94
drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100
drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786
drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0x123/0x180 fs/ioctl.c:747
__do_sys_ioctl fs/ioctl.c:756 [inline]
__se_sys_ioctl fs/ioctl.c:754 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 10244:
save_stack+0x23/0x90 mm/kasan/common.c:72
set_track mm/kasan/common.c:80 [inline]
kasan_set_free_info mm/kasan/common.c:337 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:476
kasan_slab_free+0xe/0x10 mm/kasan/common.c:485
__cache_free mm/slab.c:3426 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3757
vgem_gem_free_object+0xbe/0xe0 drivers/gpu/drm/vgem/vgem_drv.c:68
drm_gem_object_free+0x100/0x220 drivers/gpu/drm/drm_gem.c:983
kref_put include/linux/kref.h:65 [inline]
drm_gem_object_put_unlocked drivers/gpu/drm/drm_gem.c:1017 [inline]
drm_gem_object_put_unlocked+0x196/0x1c0 drivers/gpu/drm/drm_gem.c:1002
vgem_gem_create drivers/gpu/drm/vgem/vgem_drv.c:199 [inline]
vgem_gem_dumb_create+0x115/0x250 drivers/gpu/drm/vgem/vgem_drv.c:217
drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94
drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100
drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786
drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0x123/0x180 fs/ioctl.c:747
__do_sys_ioctl fs/ioctl.c:756 [inline]
__se_sys_ioctl fs/ioctl.c:754 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at ffff88809a2ee800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 264 bytes inside of
1024-byte region [ffff88809a2ee800, ffff88809a2eec00)
The buggy address belongs to the page:
page:ffffea000268bb80 refcount:1 mapcount:0 mapping:ffff8880aa400c40 index:0x0
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea0002816448 ffffea0002551bc8 ffff8880aa400c40
raw: 0000000000000000 ffff88809a2ee000 0000000100000002 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff88809a2ee800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88809a2ee880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88809a2ee900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88809a2ee980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88809a2eea00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Daniel Vetter

unread,
Feb 2, 2020, 8:17:13 AM2/2/20
to Dan Carpenter, Hillf Danton, syzbot, Dave Airlie, Alex Deucher, amd-gfx list, Wilson, Chris, Christian König, David Miller, dri-devel, Emil Velikov, Anholt, Eric, moderated list:DMA BUFFER SHARING FRAMEWORK, Linux Kernel Mailing List, open list:DMA BUFFER SHARING FRAMEWORK, netdev, Rob Clark, Sean Paul, Sumit Semwal, syzkaller-bugs
On Sat, Feb 1, 2020 at 5:26 PM Dan Carpenter <dan.ca...@oracle.com> wrote:
>
> On Sat, Feb 01, 2020 at 05:02:47PM +0800, Hillf Danton wrote:
> >
> > On Sat, 1 Feb 2020 09:17:57 +0300 Dan Carpenter wrote:
> > > On Sat, Feb 01, 2020 at 12:32:09PM +0800, Hillf Danton wrote:
> > > >
> > > > Release obj in error path.
> > > >
> > > > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > > > @@ -196,10 +196,10 @@ static struct drm_gem_object *vgem_gem_c
> > > > return ERR_CAST(obj);
> > > >
> > > > ret = drm_gem_handle_create(file, &obj->base, handle);
> > > > - drm_gem_object_put_unlocked(&obj->base);
> > > > - if (ret)
> > > > + if (ret) {
> > > > + drm_gem_object_put_unlocked(&obj->base);
> > > > return ERR_PTR(ret);
> > > > -
> > > > + }
> > > > return &obj->base;
> > >
> > > Oh yeah. It's weird that we never noticed the success path was broken.
> > > It's been that way for three years and no one noticed at all. Very
> > > strange.
> > >
> > > Anyway, it already gets freed on error in drm_gem_handle_create() so
> > > we should just delete the drm_gem_object_put_unlocked() here it looks
> > > like.

There's two refcounts here, one is the handle_count, and the other is
the underlying object refcount. I think the code is correct, except if
you race with a 2nd thread which destroys the object (through the
handle) while we still try to read gem_object->size in the caller of
this. So correct fix (I think at least) is to shuffle that temporary
reference on the object (not the handle) we hold while constructing it
around a bit, so there's no use-after free anymore in the case of a
race. I'm typing a patch for this.

Cheers, Daniel

> > Good catch, Dan :P
> > Would you please post a patch sometime convenient next week?
>
> Sure. Will do.
>
> regards,
> dan carpenter
>


--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Daniel Vetter

unread,
Feb 2, 2020, 8:19:30 AM2/2/20
to syzbot, Dave Airlie, Alex Deucher, amd-gfx list, Wilson, Chris, Christian König, David Miller, dri-devel, Emil Velikov, Anholt, Eric, moderated list:DMA BUFFER SHARING FRAMEWORK, Linux Kernel Mailing List, open list:DMA BUFFER SHARING FRAMEWORK, netdev, Rob Clark, Sean Paul, Sumit Semwal, syzkaller-bugs
On Fri, Jan 31, 2020 at 11:28 PM syzbot
<syzbot+0dc444...@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 39bed42d Merge tag 'for-linus-hmm' of git://git.kernel.org..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=179465bee00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=2646535f8818ae25
> dashboard link: https://syzkaller.appspot.com/bug?extid=0dc4444774d419e916c8
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16251279e00000
>
> The bug was bisected to:
>
> commit 7611750784664db46d0db95631e322aeb263dde7
> Author: Alex Deucher <alexande...@amd.com>
> Date: Wed Jun 21 16:31:41 2017 +0000
>
> drm/amdgpu: use kernel is_power_of_2 rather than local version
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11628df1e00000
> final crash: https://syzkaller.appspot.com/x/report.txt?x=13628df1e00000
> console output: https://syzkaller.appspot.com/x/log.txt?x=15628df1e00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+0dc444...@syzkaller.appspotmail.com
> Fixes: 761175078466 ("drm/amdgpu: use kernel is_power_of_2 rather than local version")

Aside: This bisect line is complete nonsense ... I'm kinda at the
point where I'm assuming that syzbot bisect results are garbage, which
is maybe not what we want. I guess much stricter filtering for noise
is needed, dunno.
-Danile

Dan Carpenter

unread,
Feb 3, 2020, 4:06:53 AM2/3/20
to Daniel Vetter, syzbot, Dave Airlie, Alex Deucher, amd-gfx list, Wilson, Chris, Christian König, David Miller, dri-devel, Emil Velikov, Anholt, Eric, moderated list:DMA BUFFER SHARING FRAMEWORK, Linux Kernel Mailing List, open list:DMA BUFFER SHARING FRAMEWORK, netdev, Rob Clark, Sean Paul, Sumit Semwal, syzkaller-bugs
With race conditions the git bisect is often nonsense.

regards,
dan carpenter

Christian König

unread,
Feb 3, 2020, 10:09:04 AM2/3/20
to Dan Carpenter, Daniel Vetter, syzbot, Dave Airlie, Alex Deucher, amd-gfx list, Wilson, Chris, David Miller, dri-devel, Emil Velikov, Anholt, Eric, moderated list:DMA BUFFER SHARING FRAMEWORK, Linux Kernel Mailing List, open list:DMA BUFFER SHARING FRAMEWORK, netdev, Rob Clark, Sean Paul, Sumit Semwal, syzkaller-bugs
Am 03.02.20 um 10:06 schrieb Dan Carpenter:
> On Sun, Feb 02, 2020 at 02:19:18PM +0100, Daniel Vetter wrote:
>> On Fri, Jan 31, 2020 at 11:28 PM syzbot
>> <syzbot+0dc444...@syzkaller.appspotmail.com> wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: 39bed42d Merge tag 'for-linus-hmm' of git://git.kernel.org..
>>> git tree: upstream
>>> console output: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fx%2Flog.txt%3Fx%3D179465bee00000&amp;data=02%7C01%7Cchristian.koenig%40amd.com%7C529f2273b8374f38560108d7a88862eb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637163176051177627&amp;sdata=3goGqBs4%2BjkjCeV2bX5VTB%2F1PRLEP5bzq5Ec%2BN7fKHs%3D&amp;reserved=0
>>> kernel config: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fx%2F.config%3Fx%3D2646535f8818ae25&amp;data=02%7C01%7Cchristian.koenig%40amd.com%7C529f2273b8374f38560108d7a88862eb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637163176051177627&amp;sdata=SnlKln%2FAG%2BVRVjSrOSJjUE%2BhSDf35wTqzWLCAyGQVss%3D&amp;reserved=0
>>> dashboard link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fbug%3Fextid%3D0dc4444774d419e916c8&amp;data=02%7C01%7Cchristian.koenig%40amd.com%7C529f2273b8374f38560108d7a88862eb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637163176051177627&amp;sdata=33EJNAWjTm6Edi1J0oPBfs8epb%2BQ2cpAKlzl1sT40CQ%3D&amp;reserved=0
>>> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>>> syz repro: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fx%2Frepro.syz%3Fx%3D16251279e00000&amp;data=02%7C01%7Cchristian.koenig%40amd.com%7C529f2273b8374f38560108d7a88862eb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637163176051177627&amp;sdata=zmUyyp7znqQfLzzNZ80bNgCILAjeMeCVVr7xf7CHaWk%3D&amp;reserved=0
>>>
>>> The bug was bisected to:
>>>
>>> commit 7611750784664db46d0db95631e322aeb263dde7
>>> Author: Alex Deucher <alexande...@amd.com>
>>> Date: Wed Jun 21 16:31:41 2017 +0000
>>>
>>> drm/amdgpu: use kernel is_power_of_2 rather than local version
>>>
>>> bisection log: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fx%2Fbisect.txt%3Fx%3D11628df1e00000&amp;data=02%7C01%7Cchristian.koenig%40amd.com%7C529f2273b8374f38560108d7a88862eb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637163176051177627&amp;sdata=5QpTG4iU%2FOt22L3jxRbNxtVPZZ2EvBAcFGZdqVnVCbU%3D&amp;reserved=0
>>> final crash: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fx%2Freport.txt%3Fx%3D13628df1e00000&amp;data=02%7C01%7Cchristian.koenig%40amd.com%7C529f2273b8374f38560108d7a88862eb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637163176051177627&amp;sdata=hN6UZnFR2nIMPMspjIF7S82oXstaRl%2BLAzmz5yujPac%3D&amp;reserved=0
>>> console output: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fx%2Flog.txt%3Fx%3D15628df1e00000&amp;data=02%7C01%7Cchristian.koenig%40amd.com%7C529f2273b8374f38560108d7a88862eb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637163176051177627&amp;sdata=LHXMANOURDv3EsqTSvHSBZnPEzGQoJU1RbeqYExCaGk%3D&amp;reserved=0
>>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+0dc444...@syzkaller.appspotmail.com
>>> Fixes: 761175078466 ("drm/amdgpu: use kernel is_power_of_2 rather than local version")
>> Aside: This bisect line is complete nonsense ... I'm kinda at the
>> point where I'm assuming that syzbot bisect results are garbage, which
>> is maybe not what we want. I guess much stricter filtering for noise
>> is needed, dunno.
>> -Danile
> With race conditions the git bisect is often nonsense.

Which makes sense, but we can still try to sanitize the result. I'm not
familiar with the test case, but I think it doesn't even compile the
amdgpu driver.

So skipping all patches of stuff you don't even compile would make not
only the result of bisecting quite a bit more reliable, but also speed
the process up quite a bit.

But no good idea to how teach that to a compile bot or the git bisect
command.

Regards,
Christian.

>
> regards,
> dan carpenter
>

Reply all
Reply to author
Forward
0 new messages