* [syzbot] KASAN: use-after-free Read in v4l2_ioctl (2)
@ 2021-06-25 4:53 syzbot
[not found] ` <20210625085140.1735-1-hdanton@sina.com>
0 siblings, 1 reply; 4+ messages in thread
From: syzbot @ 2021-06-25 4:53 UTC (permalink / raw)
To: ezequiel, hverkuil-cisco, lijian, linux-kernel, linux-media,
mchehab, sakari.ailus, syzkaller-bugs
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+19c5a4b75931e8d63aab@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 syzkaller@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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] KASAN: use-after-free Read in v4l2_ioctl (2)
[not found] ` <20210625085140.1735-1-hdanton@sina.com>
@ 2021-06-25 9:08 ` Dmitry Vyukov
[not found] ` <20210625094638.1791-1-hdanton@sina.com>
0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Vyukov @ 2021-06-25 9:08 UTC (permalink / raw)
To: Hillf Danton
Cc: syzbot, ezequiel, hverkuil-cisco, lijian, linux-kernel,
linux-media, mchehab, sakari.ailus, syzkaller-bugs
On Fri, Jun 25, 2021 at 10:52 AM Hillf Danton <hdanton@sina.com> wrote:
>
> On Thu, 24 Jun 2021 21:53:15 -0700
> > 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+19c5a4b75931e8d63aab@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
> > ==================================================================
>
> 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?
> + }
> 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);
> }
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] KASAN: use-after-free Read in v4l2_ioctl (2)
[not found] ` <20210625094638.1791-1-hdanton@sina.com>
@ 2021-06-25 9:53 ` Dmitry Vyukov
[not found] ` <20210625130813.84-1-hdanton@sina.com>
0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Vyukov @ 2021-06-25 9:53 UTC (permalink / raw)
To: Hillf Danton
Cc: syzbot, ezequiel, hverkuil-cisco, lijian, linux-kernel,
linux-media, mchehab, sakari.ailus, syzkaller-bugs
On Fri, Jun 25, 2021 at 11:46 AM Hillf Danton <hdanton@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 :)
> Thanks for taking a look at it.
>
> Hillf
> >
> >
> >> + }
> >> 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);
> >> }
>
> --
> 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-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20210625094638.1791-1-hdanton%40sina.com.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] KASAN: use-after-free Read in v4l2_ioctl (2)
[not found] ` <20210625130813.84-1-hdanton@sina.com>
@ 2021-06-25 13:51 ` Dmitry Vyukov
0 siblings, 0 replies; 4+ messages in thread
From: Dmitry Vyukov @ 2021-06-25 13:51 UTC (permalink / raw)
To: Hillf Danton
Cc: syzbot, ezequiel, hverkuil-cisco, lijian, linux-kernel,
linux-media, mchehab, sakari.ailus, syzkaller-bugs
On Fri, Jun 25, 2021 at 3:08 PM Hillf Danton <hdanton@sina.com> 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.
>
> 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.
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
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-06-25 13:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-25 4:53 [syzbot] KASAN: use-after-free Read in v4l2_ioctl (2) syzbot
[not found] ` <20210625085140.1735-1-hdanton@sina.com>
2021-06-25 9:08 ` Dmitry Vyukov
[not found] ` <20210625094638.1791-1-hdanton@sina.com>
2021-06-25 9:53 ` Dmitry Vyukov
[not found] ` <20210625130813.84-1-hdanton@sina.com>
2021-06-25 13:51 ` Dmitry Vyukov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).