[syzbot] KASAN: use-after-free Read in v4l2_ioctl (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: a1f92694 Add linux-next specific files for 20210518
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12cb6184300000
kernel config: https://syzkaller.appspot.com/x/.config?x=d612e75ffd53a6d3
dashboard link: https://syzkaller.appspot.com/bug?extid=19c5a4b75931e8d63aab
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13f87f20300000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11f82d34300000

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

==================================================================
BUG: KASAN: use-after-free in v4l2_ioctl+0x1f1/0x250 drivers/media/v4l2-core/v4l2-dev.c:364
Read of size 8 at addr ffff88801dc54398 by task v4l_id/25000

CPU: 0 PID: 25000 Comm: v4l_id Not tainted 5.13.0-rc2-next-20210518-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x13e/0x1d6 lib/dump_stack.c:129
print_address_description.constprop.0.cold+0x6c/0x309 mm/kasan/report.c:233
__kasan_report mm/kasan/report.c:419 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:436
v4l2_ioctl+0x1f1/0x250 drivers/media/v4l2-core/v4l2-dev.c:364
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:1069 [inline]
__se_sys_ioctl fs/ioctl.c:1055 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:1055
do_syscall_64+0x31/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f30112bb017
Code: 00 00 00 48 8b 05 81 7e 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 51 7e 2b 00 f7 d8 64 89 01 48
RSP: 002b:00007ffcfc119d68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f30112bb017
RDX: 00007ffcfc119d70 RSI: 0000000080685600 RDI: 0000000000000003
RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000002 R11: 0000000000000246 R12: 000055f2227cb8d0
R13: 00007ffcfc119ed0 R14: 0000000000000000 R15: 0000000000000000

Allocated by task 12321:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:46 [inline]
set_alloc_info mm/kasan/common.c:431 [inline]
____kasan_kmalloc mm/kasan/common.c:510 [inline]
____kasan_kmalloc mm/kasan/common.c:469 [inline]
__kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:519
kmalloc include/linux/slab.h:590 [inline]
kzalloc include/linux/slab.h:720 [inline]
stk_camera_probe+0x7d/0xc50 drivers/media/usb/stkwebcam/stk-webcam.c:1281
usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
really_probe+0x291/0xf60 drivers/base/dd.c:576
driver_probe_device+0x298/0x410 drivers/base/dd.c:763
__device_attach_driver+0x203/0x2c0 drivers/base/dd.c:870
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
__device_attach+0x228/0x4a0 drivers/base/dd.c:938
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
device_add+0xbe0/0x2100 drivers/base/core.c:3320
usb_set_configuration+0x113f/0x1910 drivers/usb/core/message.c:2164
usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
really_probe+0x291/0xf60 drivers/base/dd.c:576
driver_probe_device+0x298/0x410 drivers/base/dd.c:763
__device_attach_driver+0x203/0x2c0 drivers/base/dd.c:870
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
__device_attach+0x228/0x4a0 drivers/base/dd.c:938
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
device_add+0xbe0/0x2100 drivers/base/core.c:3320
usb_new_device.cold+0x721/0x1058 drivers/usb/core/hub.c:2556
hub_port_connect drivers/usb/core/hub.c:5276 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5416 [inline]
port_event drivers/usb/core/hub.c:5562 [inline]
hub_event+0x2357/0x4330 drivers/usb/core/hub.c:5644
process_one_work+0x98d/0x1600 kernel/workqueue.c:2275
worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
kthread+0x3b1/0x4a0 kernel/kthread.c:313
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294

Freed by task 16814:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track+0x1c/0x30 mm/kasan/common.c:46
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357
____kasan_slab_free mm/kasan/common.c:363 [inline]
____kasan_slab_free mm/kasan/common.c:328 [inline]
__kasan_slab_free+0xfb/0x130 mm/kasan/common.c:371
kasan_slab_free include/linux/kasan.h:212 [inline]
slab_free_hook mm/slub.c:1623 [inline]
slab_free_freelist_hook+0xdf/0x240 mm/slub.c:1648
slab_free mm/slub.c:3208 [inline]
kfree+0xeb/0x650 mm/slub.c:4274
usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458
__device_release_driver+0x3bd/0x6f0 drivers/base/dd.c:1181
device_release_driver_internal drivers/base/dd.c:1212 [inline]
device_release_driver+0x26/0x40 drivers/base/dd.c:1235
bus_remove_device+0x2eb/0x5a0 drivers/base/bus.c:533
device_del+0x502/0xd40 drivers/base/core.c:3508
usb_disable_device+0x35b/0x7b0 drivers/usb/core/message.c:1413
usb_disconnect.cold+0x27a/0x78e drivers/usb/core/hub.c:2219
hub_port_connect drivers/usb/core/hub.c:5127 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5416 [inline]
port_event drivers/usb/core/hub.c:5562 [inline]
hub_event+0x1c9c/0x4330 drivers/usb/core/hub.c:5644
process_one_work+0x98d/0x1600 kernel/workqueue.c:2275
worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
kthread+0x3b1/0x4a0 kernel/kthread.c:313
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294

The buggy address belongs to the object at ffff88801dc54000
which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 920 bytes inside of
4096-byte region [ffff88801dc54000, ffff88801dc55000)
The buggy address belongs to the page:
page:ffffea0000771400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1dc50
head:ffffea0000771400 order:3 compound_mapcount:0 compound_pincount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 0000000000000000 0000000100000001 ffff888011042140
raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2040(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 11559, ts 1619924100847, free_ts 1619644095689
prep_new_page mm/page_alloc.c:2377 [inline]
get_page_from_freelist+0x125c/0x2ed0 mm/page_alloc.c:4038
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5239
alloc_pages+0x18c/0x2a0 mm/mempolicy.c:2272
alloc_slab_page mm/slub.c:1686 [inline]
allocate_slab+0x2c2/0x4c0 mm/slub.c:1826
new_slab mm/slub.c:1889 [inline]
new_slab_objects mm/slub.c:2635 [inline]
___slab_alloc+0x4ba/0x820 mm/slub.c:2798
__slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2838
slab_alloc_node mm/slub.c:2920 [inline]
slab_alloc mm/slub.c:2962 [inline]
__kmalloc+0x312/0x330 mm/slub.c:4112
kmalloc include/linux/slab.h:595 [inline]
tomoyo_realpath_from_path+0xc3/0x620 security/tomoyo/realpath.c:254
tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
tomoyo_path_perm+0x21b/0x400 security/tomoyo/file.c:822
security_inode_getattr+0xcf/0x140 security/security.c:1332
vfs_getattr fs/stat.c:139 [inline]
vfs_statx+0x164/0x390 fs/stat.c:207
vfs_fstatat fs/stat.c:225 [inline]
vfs_lstat include/linux/fs.h:3384 [inline]
__do_sys_newlstat+0x91/0x110 fs/stat.c:380
do_syscall_64+0x31/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0x44/0xae
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1305 [inline]
__free_pages_ok+0x4cb/0xf30 mm/page_alloc.c:1586
qlink_free mm/kasan/quarantine.c:146 [inline]
qlist_free_all+0x5a/0xc0 mm/kasan/quarantine.c:165
kasan_quarantine_reduce+0x180/0x200 mm/kasan/quarantine.c:272
__kasan_slab_alloc+0x8e/0xa0 mm/kasan/common.c:441
kasan_slab_alloc include/linux/kasan.h:236 [inline]
slab_post_alloc_hook mm/slab.h:512 [inline]
slab_alloc_node mm/slub.c:2954 [inline]
slab_alloc mm/slub.c:2962 [inline]
kmem_cache_alloc+0x285/0x4a0 mm/slub.c:2967
getname_flags.part.0+0x50/0x4f0 fs/namei.c:138
getname_flags include/linux/audit.h:319 [inline]
getname fs/namei.c:209 [inline]
__do_sys_unlink fs/namei.c:4139 [inline]
__se_sys_unlink fs/namei.c:4137 [inline]
__x64_sys_unlink+0xb1/0x100 fs/namei.c:4137
do_syscall_64+0x31/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0x44/0xae

Memory state around the buggy address:
ffff88801dc54280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88801dc54300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88801dc54380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88801dc54400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88801dc54480: 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 can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: use-after-free Read in v4l2_release

==================================================================
BUG: KASAN: use-after-free in v4l2_release+0x326/0x3b0 drivers/media/v4l2-core/v4l2-dev.c:453
Read of size 8 at addr ffff8880349c2398 by task v4l_id/11172

CPU: 1 PID: 11172 Comm: v4l_id Not tainted 5.13.0-rc7-next-20210624-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]

dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:105

print_address_description.constprop.0.cold+0x6c/0x309 mm/kasan/report.c:233
__kasan_report mm/kasan/report.c:419 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:436

v4l2_release+0x326/0x3b0 drivers/media/v4l2-core/v4l2-dev.c:453
__fput+0x288/0x920 fs/file_table.c:280
task_work_run+0xdd/0x1a0 kernel/task_work.c:164
tracehook_notify_resume include/linux/tracehook.h:189 [inline]
exit_to_user_mode_loop kernel/entry/common.c:175 [inline]
exit_to_user_mode_prepare+0x27e/0x290 kernel/entry/common.c:209
__syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f79a29c6270
Code: 73 01 c3 48 8b 0d 38 7d 20 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 59 c1 20 00 00 75 10 b8 03 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24
RSP: 002b:00007ffc4af3b2c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 00007f79a29c6270
RDX: 000000000000000a RSI: 00007f79a29b2760 RDI: 0000000000000003
RBP: 00007f79a2ff7698 R08: 00007f79a29b2760 R09: 00007f79a2ff7700
R10: 000055b874a93ee3 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffc4af3b450 R14: 0000000000000000 R15: 0000000000000000

Allocated by task 10153:

kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:46 [inline]
set_alloc_info mm/kasan/common.c:431 [inline]
____kasan_kmalloc mm/kasan/common.c:510 [inline]
____kasan_kmalloc mm/kasan/common.c:469 [inline]
__kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:519

kmalloc include/linux/slab.h:591 [inline]
kzalloc include/linux/slab.h:721 [inline]

stk_camera_probe+0x7d/0xc50 drivers/media/usb/stkwebcam/stk-webcam.c:1281
usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396

call_driver_probe drivers/base/dd.c:517 [inline]
really_probe+0x23c/0xcd0 drivers/base/dd.c:595
__driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
__device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
__device_attach+0x228/0x4a0 drivers/base/dd.c:965
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
device_add+0xc2f/0x2180 drivers/base/core.c:3356
usb_set_configuration+0x113f/0x1910 drivers/usb/core/message.c:2170

usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293

call_driver_probe drivers/base/dd.c:517 [inline]
really_probe+0x23c/0xcd0 drivers/base/dd.c:595
__driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
__device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
__device_attach+0x228/0x4a0 drivers/base/dd.c:965
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
device_add+0xc2f/0x2180 drivers/base/core.c:3356
usb_new_device.cold+0x63f/0x108e drivers/usb/core/hub.c:2559
hub_port_connect drivers/usb/core/hub.c:5300 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5440 [inline]
port_event drivers/usb/core/hub.c:5586 [inline]
hub_event+0x2357/0x4330 drivers/usb/core/hub.c:5668
process_one_work+0x98d/0x1630 kernel/workqueue.c:2273
worker_thread+0x658/0x11f0 kernel/workqueue.c:2419
kthread+0x3e5/0x4d0 kernel/kthread.c:319
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295

Freed by task 10189:

kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track+0x1c/0x30 mm/kasan/common.c:46
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357
____kasan_slab_free mm/kasan/common.c:363 [inline]
____kasan_slab_free mm/kasan/common.c:328 [inline]
__kasan_slab_free+0xfb/0x130 mm/kasan/common.c:371

kasan_slab_free include/linux/kasan.h:229 [inline]
slab_free_hook mm/slub.c:1650 [inline]
slab_free_freelist_hook+0xdf/0x240 mm/slub.c:1675
slab_free mm/slub.c:3235 [inline]
kfree+0xeb/0x650 mm/slub.c:4295
usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458
__device_release_driver+0x3bd/0x6f0 drivers/base/dd.c:1201
device_release_driver_internal drivers/base/dd.c:1232 [inline]
device_release_driver+0x26/0x40 drivers/base/dd.c:1255
bus_remove_device+0x2eb/0x5a0 drivers/base/bus.c:529
device_del+0x502/0xd40 drivers/base/core.c:3544
usb_disable_device+0x35b/0x7b0 drivers/usb/core/message.c:1419
usb_disconnect.cold+0x27a/0x78e drivers/usb/core/hub.c:2221
hub_port_connect drivers/usb/core/hub.c:5151 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5440 [inline]
port_event drivers/usb/core/hub.c:5586 [inline]
hub_event+0x1c9c/0x4330 drivers/usb/core/hub.c:5668
process_one_work+0x98d/0x1630 kernel/workqueue.c:2273
worker_thread+0x658/0x11f0 kernel/workqueue.c:2419
kthread+0x3e5/0x4d0 kernel/kthread.c:319
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295

The buggy address belongs to the object at ffff8880349c2000

which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 920 bytes inside of

4096-byte region [ffff8880349c2000, ffff8880349c3000)

The buggy address belongs to the page:

page:ffffea0000d27000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x349c0
head:ffffea0000d27000 order:3 compound_mapcount:0 compound_pincount:0

flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)

raw: 00fff00000010200 0000000000000000 0000000300000001 ffff888010842140

raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated

page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2040(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 8398, ts 62980201379, free_ts 62971399957
prep_new_page mm/page_alloc.c:2444 [inline]
get_page_from_freelist+0xa72/0x2f80 mm/page_alloc.c:4177
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5385
alloc_pages+0x18c/0x2a0 mm/mempolicy.c:2244
alloc_slab_page mm/slub.c:1713 [inline]
allocate_slab+0x32b/0x4c0 mm/slub.c:1853
new_slab mm/slub.c:1916 [inline]
new_slab_objects mm/slub.c:2662 [inline]
___slab_alloc+0x4ba/0x820 mm/slub.c:2825
__slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2865
slab_alloc_node mm/slub.c:2947 [inline]
slab_alloc mm/slub.c:2989 [inline]
__kmalloc+0x312/0x330 mm/slub.c:4133
kmalloc include/linux/slab.h:596 [inline]

tomoyo_realpath_from_path+0xc3/0x620 security/tomoyo/realpath.c:254
tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
tomoyo_path_perm+0x21b/0x400 security/tomoyo/file.c:822
security_inode_getattr+0xcf/0x140 security/security.c:1332
vfs_getattr fs/stat.c:139 [inline]
vfs_statx+0x164/0x390 fs/stat.c:207
vfs_fstatat fs/stat.c:225 [inline]

__do_sys_newfstatat+0x96/0x120 fs/stat.c:394
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80

entry_SYSCALL_64_after_hwframe+0x44/0xae
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]

free_pages_prepare mm/page_alloc.c:1354 [inline]
free_pcp_prepare+0x312/0x7d0 mm/page_alloc.c:1405
free_unref_page_prepare mm/page_alloc.c:3340 [inline]
free_unref_page+0x19/0x690 mm/page_alloc.c:3419

qlink_free mm/kasan/quarantine.c:146 [inline]
qlist_free_all+0x5a/0xc0 mm/kasan/quarantine.c:165
kasan_quarantine_reduce+0x180/0x200 mm/kasan/quarantine.c:272
__kasan_slab_alloc+0x8e/0xa0 mm/kasan/common.c:441

kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slab.h:512 [inline]
slab_alloc_node mm/slub.c:2981 [inline]
slab_alloc mm/slub.c:2989 [inline]
kmem_cache_alloc_trace+0x26d/0x3c0 mm/slub.c:3006
kmalloc include/linux/slab.h:591 [inline]
kzalloc include/linux/slab.h:721 [inline]
alloc_tty_struct+0x95/0x920 drivers/tty/tty_io.c:3122
tty_init_dev.part.0+0x20/0x610 drivers/tty/tty_io.c:1422
tty_init_dev include/linux/err.h:36 [inline]
tty_open_by_driver drivers/tty/tty_io.c:2098 [inline]
tty_open+0xb16/0x1000 drivers/tty/tty_io.c:2146
chrdev_open+0x266/0x770 fs/char_dev.c:414
do_dentry_open+0x4c8/0x11d0 fs/open.c:826
do_open fs/namei.c:3393 [inline]
path_openat+0x1c23/0x27f0 fs/namei.c:3526
do_filp_open+0x1aa/0x400 fs/namei.c:3553
do_sys_openat2+0x16d/0x420 fs/open.c:1204
do_sys_open fs/open.c:1220 [inline]
__do_sys_open fs/open.c:1228 [inline]
__se_sys_open fs/open.c:1224 [inline]
__x64_sys_open+0x119/0x1c0 fs/open.c:1224
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80

Memory state around the buggy address:

ffff8880349c2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880349c2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880349c2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880349c2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880349c2480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


Tested on:

commit: 2a8927f0 Add linux-next specific files for 20210624
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=101c670c300000
kernel config: https://syzkaller.appspot.com/x/.config?x=87b765d51e7c3b4b
dashboard link: https://syzkaller.appspot.com/bug?extid=19c5a4b75931e8d63aab
compiler:

[Hillf Danton]

On Thu, 24 Jun 2021 21:53:15 -0700

Given the uaf in the ioctl path, open count is needed and should be
maintained by stk and is implemented in the diff below with mutex - it
is locked at file open time, released at file release time and aquired
at disconnect time.

This can be a quick fix to the uaf, though, lights on why the video_get(vdev)
in v4l2_open() fails to prevent stk camera from going home too early are
welcome. Is it the fault on the driver side without an eye on open count?

+++ x/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -624,8 +624,10 @@ static int v4l_stk_open(struct file *fp)
dev->first_init = 0;

err = v4l2_fh_open(fp);
- if (!err)
+ if (!err) {
usb_autopm_get_interface(dev->interface);
+ mutex_trylock(&dev->free_mutex);
+ }
mutex_unlock(&dev->lock);
return err;
}
@@ -633,6 +635,7 @@ static int v4l_stk_open(struct file *fp)
static int v4l_stk_release(struct file *fp)
{
struct stk_camera *dev = video_drvdata(fp);
+ int rc;

mutex_lock(&dev->lock);
if (dev->owner == fp) {
@@ -645,7 +648,9 @@ static int v4l_stk_release(struct file *

usb_autopm_put_interface(dev->interface);
mutex_unlock(&dev->lock);
- return v4l2_fh_release(fp);
+ rc = v4l2_fh_release(fp);
+ mutex_unlock(&dev->free_mutex);
+ return rc;
}

static ssize_t stk_read(struct file *fp, char __user *buf,
@@ -1306,6 +1311,7 @@ static int stk_camera_probe(struct usb_i

spin_lock_init(&dev->spinlock);
mutex_init(&dev->lock);
+ mutex_init(&dev->free_mutex);
init_waitqueue_head(&dev->wait_frame);
dev->first_init = 1; /* webcam LED management */

@@ -1385,6 +1391,8 @@ static void stk_camera_disconnect(struct
video_unregister_device(&dev->vdev);
v4l2_ctrl_handler_free(&dev->hdl);
v4l2_device_unregister(&dev->v4l2_dev);
+ mutex_lock(&dev->free_mutex);
+ mutex_unlock(&dev->free_mutex);
kfree(dev);
}

[Dmitry Vyukov]

I haven't read all of it, but doing mutex_trylock w/o checking the
return value looks very fishy. Can it ever be the right thing to
do?... E.g. the next line we unconditionally do mutex_unlock, are we
potentially unlocking a non-locked mutex?

[Hillf Danton]

On Fri, 25 Jun 2021 11:08:57 +0200 Dmitry Vyukov wrote:

>On Fri, Jun 25, 2021 at 10:52 AM Hillf Danton wrote:
>>
>> Given the uaf in the ioctl path, open count is needed and should be
>> maintained by stk and is implemented in the diff below with mutex - it
>> is locked at file open time, released at file release time and aquired
>> at disconnect time.
>>
>> This can be a quick fix to the uaf, though, lights on why the video_get(vdev)
>> in v4l2_open() fails to prevent stk camera from going home too early are
>> welcome. Is it the fault on the driver side without an eye on open count?
>>
>> +++ x/drivers/media/usb/stkwebcam/stk-webcam.c
>> @@ -624,8 +624,10 @@ static int v4l_stk_open(struct file *fp)
>> dev->first_init = 0;
>>
>> err = v4l2_fh_open(fp);
>> - if (!err)
>> + if (!err) {
>> usb_autopm_get_interface(dev->interface);
>> + mutex_trylock(&dev->free_mutex);
>
>I haven't read all of it, but doing mutex_trylock w/o checking the
>return value looks very fishy. Can it ever be the right thing to
>do?... E.g. the next line we unconditionally do mutex_unlock, are we
>potentially unlocking a non-locked mutex?

I am having difficulty understanding your point until I see next line...
we have the same habit in regard to replying mails that deliver fix out
of our boxes.

What is your local time now? Wakeup without downing a pint of black tea?
Or still working in the late night?

Thanks for taking a look at it.

Hillf

[Dmitry Vyukov]

On Fri, Jun 25, 2021 at 11:46 AM Hillf Danton <hda...@sina.com> wrote:
>
> On Fri, 25 Jun 2021 11:08:57 +0200 Dmitry Vyukov wrote:
> >On Fri, Jun 25, 2021 at 10:52 AM Hillf Danton wrote:
> >>
> >> Given the uaf in the ioctl path, open count is needed and should be
> >> maintained by stk and is implemented in the diff below with mutex - it
> >> is locked at file open time, released at file release time and aquired
> >> at disconnect time.
> >>
> >> This can be a quick fix to the uaf, though, lights on why the video_get(vdev)
> >> in v4l2_open() fails to prevent stk camera from going home too early are
> >> welcome. Is it the fault on the driver side without an eye on open count?
> >>
> >> +++ x/drivers/media/usb/stkwebcam/stk-webcam.c
> >> @@ -624,8 +624,10 @@ static int v4l_stk_open(struct file *fp)
> >> dev->first_init = 0;
> >>
> >> err = v4l2_fh_open(fp);
> >> - if (!err)
> >> + if (!err) {
> >> usb_autopm_get_interface(dev->interface);
> >> + mutex_trylock(&dev->free_mutex);
> >
> >I haven't read all of it, but doing mutex_trylock w/o checking the
> >return value looks very fishy. Can it ever be the right thing to
> >do?... E.g. the next line we unconditionally do mutex_unlock, are we
> >potentially unlocking a non-locked mutex?
>
> I am having difficulty understanding your point until I see next line...

Right, the next line unlocks a different mutex, so ignore the part
about the next line.

But I am still confused about the intention of trylock w/o using the
return value. I fail to imagine any scenarios where it's the right
thing to do.

> we have the same habit in regard to replying mails that deliver fix out
> of our boxes.
>
> What is your local time now? Wakeup without downing a pint of black tea?
> Or still working in the late night?

It's 11:53am, so I am properly caffeinated already :)

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20210625094638.1791-1-hdanton%40sina.com.

[Hillf Danton]

On Fri, 25 Jun 2021 11:53:59 +0200 Dmitry Vyukov wrote:

Let me explain. The whole point of the added mutex is solely to prevent
the disconnector from freeing the stk camera while there are still
openers of the video device, and trylock is used to walk around deadlock
because multiple openers are allowed. In function it is equivelant to the
usual method on top of open count and waitqueue, something like

mutex_lock;
stk_cam->open_cnt++; // mutex_trylock(&stk_cam->free_mutex);
mutex_unlock;

at file open time, and

mutex_lock;
stk_cam->open_cnt = 0;
wake_up(&stk_cam->waitq); // mutex_unlock(&stk_cam->free_mutex);
mutex_unlock;

at file release time, and

wait_event(stk_cam->waitq,
stk_cam->open_cnt == 0); // mutex_lock(&stk_cam->free_mutex);
// mutex_unlock(&stk_cam->free_mutex);
kfree(stk_cam);

at disconnect time, but has fewer lines of code to type.

What is more crucial however is why the mechanisms in video core are
failing to prevent uaf like this one from coming true. Lets wait for
lights from the video folks.

Hillf

[Dmitry Vyukov]

But if trylock has failed, then the file release will still unlock the
mutex and unlocking a mutex without a prior lock is not permitted.

Or, I assume disconnect needs to wait for all files to be released.
This won't be the case with a mutex, because when the first file is
released, mutex is unlocked and disconnect can proceed.

But maybe I am still missing something.
Are you sure your use of mutex complies with the rules?
https://elixir.bootlin.com/linux/v5.13-rc7/source/include/linux/mutex.h#L31

[Hillf Danton]

On Fri, 25 Jun 2021 15:51:32 +0200 Dmitry Vyukov wrote:

You are right.

>
>Or, I assume disconnect needs to wait for all files to be released.

Correct.

>This won't be the case with a mutex, because when the first file is
>released, mutex is unlocked and disconnect can proceed.
>
>But maybe I am still missing something.
>Are you sure your use of mutex complies with the rules?
>https://elixir.bootlin.com/linux/v5.13-rc7/source/include/linux/mutex.h#L31

Frankly it also breaks another

* - only the owner can unlock the mutex

and falls into the class that is too hacky to take off.

Apart from the open count and waitqueue method, this uaf can be fixed based
on the refcount maintained in the video core, see v4l2_open().

+++ x/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -1233,7 +1233,10 @@ static void stk_v4l_dev_release(struct v

if (dev->sio_bufs != NULL || dev->isobufs != NULL)
pr_err("We are leaking memory\n");
+
+ /* take a look at v4l2_device_release() */
usb_put_intf(dev->interface);
+ kfree(dev);
}

static const struct video_device stk_v4l_data = {
@@ -1385,7 +1388,7 @@ static void stk_camera_disconnect(struct

video_unregister_device(&dev->vdev);
v4l2_ctrl_handler_free(&dev->hdl);
v4l2_device_unregister(&dev->v4l2_dev);

- kfree(dev);
+ /* kfree(dev) in stk_v4l_dev_release() */
}

#ifdef CONFIG_PM

[syzbot]

Auto-closing this bug as obsolete.
No recent activity, existing reproducers are no longer triggering the issue.