KASAN: use-after-free Read in vgem_fence_attach_ioctl

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: f5d8eef0 Linux 4.19.154
git tree: linux-4.19.y
console output: https://syzkaller.appspot.com/x/log.txt?x=10f43d8a500000
kernel config: https://syzkaller.appspot.com/x/.config?x=be9b9357b4680aa1
dashboard link: https://syzkaller.appspot.com/bug?extid=8ed5a073e72406127608
compiler: gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8ed5a0...@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x2cb4/0x3ff0 kernel/locking/lockdep.c:3294
Read of size 8 at addr ffff8880962c1420 by task syz-executor.5/20683

CPU: 0 PID: 20683 Comm: syz-executor.5 Not tainted 4.19.154-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+0x1fc/0x2fe lib/dump_stack.c:118
print_address_description.cold+0x54/0x219 mm/kasan/report.c:256
kasan_report_error.cold+0x8a/0x1c7 mm/kasan/report.c:354
kasan_report mm/kasan/report.c:412 [inline]
__asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433
__lock_acquire+0x2cb4/0x3ff0 kernel/locking/lockdep.c:3294
lock_acquire+0x170/0x3c0 kernel/locking/lockdep.c:3907
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__ww_mutex_lock.constprop.0+0x141/0x2cb0 kernel/locking/mutex.c:1080
reservation_object_lock include/linux/reservation.h:166 [inline]
vgem_fence_attach_ioctl+0x3ef/0x640 drivers/gpu/drm/vgem/vgem_fence.c:193
drm_ioctl_kernel+0x208/0x2a0 drivers/gpu/drm/drm_ioctl.c:757
drm_ioctl+0x507/0x9c0 drivers/gpu/drm/drm_ioctl.c:857
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0xcdb/0x12e0 fs/ioctl.c:688
ksys_ioctl+0x9b/0xc0 fs/ioctl.c:705
__do_sys_ioctl fs/ioctl.c:712 [inline]
__se_sys_ioctl fs/ioctl.c:710 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:710
do_syscall_64+0xf9/0x620 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45deb9
Code: 0d b4 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 db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f70b22b9c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 000000000000c5c0 RCX: 000000000045deb9
RDX: 0000000020000140 RSI: 00000000c10c5541 RDI: 0000000000000004
RBP: 000000000118bf60 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118bf2c
R13: 00007ffe4899b09f R14: 00007f70b22ba9c0 R15: 000000000118bf2c

Allocated by task 20683:
__do_kmalloc mm/slab.c:3727 [inline]
__kmalloc+0x15a/0x3c0 mm/slab.c:3736
kmalloc include/linux/slab.h:520 [inline]
kzalloc include/linux/slab.h:709 [inline]
dma_buf_export+0x1f1/0xa20 drivers/dma-buf/dma-buf.c:416
drm_gem_dmabuf_export+0x17/0x80 drivers/gpu/drm/drm_prime.c:365
drm_gem_prime_export+0x182/0x200 drivers/gpu/drm/drm_prime.c:546
attach_dmabuf drivers/gpu/drm/vgem/vgem_fence.c:124 [inline]
vgem_fence_attach_ioctl+0x395/0x640 drivers/gpu/drm/vgem/vgem_fence.c:173
drm_ioctl_kernel+0x208/0x2a0 drivers/gpu/drm/drm_ioctl.c:757
drm_ioctl+0x507/0x9c0 drivers/gpu/drm/drm_ioctl.c:857
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0xcdb/0x12e0 fs/ioctl.c:688
ksys_ioctl+0x9b/0xc0 fs/ioctl.c:705
__do_sys_ioctl fs/ioctl.c:712 [inline]
__se_sys_ioctl fs/ioctl.c:710 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:710
do_syscall_64+0xf9/0x620 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 20684:
__cache_free mm/slab.c:3503 [inline]
kfree+0xcc/0x210 mm/slab.c:3822
dma_buf_release+0x329/0x630 drivers/dma-buf/dma-buf.c:80
__fput+0x2ce/0x890 fs/file_table.c:278
task_work_run+0x148/0x1c0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x251/0x2a0 arch/x86/entry/common.c:167
prepare_exit_to_usermode arch/x86/entry/common.c:198 [inline]
syscall_return_slowpath arch/x86/entry/common.c:271 [inline]
do_syscall_64+0x538/0x620 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at ffff8880962c1240
which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 480 bytes inside of
1024-byte region [ffff8880962c1240, ffff8880962c1640)
The buggy address belongs to the page:
page:ffffea000258b000 count:1 mapcount:0 mapping:ffff88813bff0ac0 index:0x0 compound_mapcount: 0
flags: 0xfff00000008100(slab|head)
raw: 00fff00000008100 ffffea000176c888 ffffea0000f16608 ffff88813bff0ac0
raw: 0000000000000000 ffff8880962c0040 0000000100000007 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff8880962c1300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880962c1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880962c1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880962c1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880962c1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


---
This report 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 issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.