On Sat, 29 Aug 2020 05:50:43 +0200, Hillf Danton wrote: > > > Thu, 27 Aug 2020 09:34:15 -0700 > > syzbot found the following issue on: > > > > HEAD commit: f37be724 Add linux-next specific files for 20200826 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=137c7cb9900000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=1e5a1cf036089d95 > > dashboard link: https://syzkaller.appspot.com/bug?extid=12a3fcd1493ec6585007 > > 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+12a3fcd1493ec6585007@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > ================================================================== > > BUG: KASAN: use-after-free in snd_pcm_oss_release_file sound/core/oss/pcm_oss.c:2367 [inline] > > BUG: KASAN: use-after-free in snd_pcm_oss_release_file sound/core/oss/pcm_oss.c:2361 [inline] > > BUG: KASAN: use-after-free in snd_pcm_oss_release+0x28d/0x300 sound/core/oss/pcm_oss.c:2548 > > Read of size 8 at addr ffff888026b66480 by task syz-executor.1/27751 > > > > CPU: 1 PID: 27751 Comm: syz-executor.1 Not tainted 5.9.0-rc2-next-20200826-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+0x18f/0x20d lib/dump_stack.c:118 > > print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383 > > __kasan_report mm/kasan/report.c:513 [inline] > > kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 > > snd_pcm_oss_release_file sound/core/oss/pcm_oss.c:2367 [inline] > > snd_pcm_oss_release_file sound/core/oss/pcm_oss.c:2361 [inline] > > snd_pcm_oss_release+0x28d/0x300 sound/core/oss/pcm_oss.c:2548 > > __fput+0x285/0x920 fs/file_table.c:281 > > task_work_run+0xdd/0x190 kernel/task_work.c:141 > > tracehook_notify_resume include/linux/tracehook.h:188 [inline] > > exit_to_user_mode_loop kernel/entry/common.c:140 [inline] > > exit_to_user_mode_prepare+0x195/0x1c0 kernel/entry/common.c:167 > > syscall_exit_to_user_mode+0x59/0x2b0 kernel/entry/common.c:242 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > RIP: 0033:0x416f01 > > Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 > > RSP: 002b:00007ffdd39a5e70 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 > > RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000416f01 > > RDX: 0000000000000001 RSI: 0000000001190428 RDI: 0000000000000003 > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > > R10: 00007ffdd39a5f60 R11: 0000000000000293 R12: 0000000001190428 > > R13: 0000000000268c54 R14: ffffffffffffffff R15: 000000000118cfec > > > > Allocated by task 27754: > > kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 > > kasan_set_track mm/kasan/common.c:56 [inline] > > __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461 > > kmem_cache_alloc_trace+0x16e/0x2c0 mm/slab.c:3550 > > kmalloc include/linux/slab.h:554 [inline] > > kzalloc include/linux/slab.h:666 [inline] > > snd_pcm_oss_open_file sound/core/oss/pcm_oss.c:2389 [inline] > > snd_pcm_oss_open.part.0+0x55e/0x1290 sound/core/oss/pcm_oss.c:2491 > > snd_pcm_oss_open+0x3c/0x50 sound/core/oss/pcm_oss.c:2455 > > soundcore_open+0x445/0x600 sound/sound_core.c:593 > > chrdev_open+0x266/0x770 fs/char_dev.c:414 > > do_dentry_open+0x4b9/0x11b0 fs/open.c:817 > > do_open fs/namei.c:3251 [inline] > > path_openat+0x1b9a/0x2730 fs/namei.c:3368 > > do_filp_open+0x17e/0x3c0 fs/namei.c:3395 > > do_sys_openat2+0x16d/0x420 fs/open.c:1168 > > do_sys_open fs/open.c:1184 [inline] > > __do_sys_openat fs/open.c:1200 [inline] > > __se_sys_openat fs/open.c:1195 [inline] > > __x64_sys_openat+0x13f/0x1f0 fs/open.c:1195 > > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > Freed by task 27754: > > kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 > > kasan_set_track+0x1c/0x30 mm/kasan/common.c:56 > > kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355 > > __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422 > > __cache_free mm/slab.c:3418 [inline] > > kfree+0x103/0x2c0 mm/slab.c:3756 > > snd_pcm_oss_release_file sound/core/oss/pcm_oss.c:2371 [inline] > > snd_pcm_oss_release_file sound/core/oss/pcm_oss.c:2361 [inline] > > snd_pcm_oss_release+0x17e/0x300 sound/core/oss/pcm_oss.c:2548 > > __fput+0x285/0x920 fs/file_table.c:281 > > task_work_run+0xdd/0x190 kernel/task_work.c:141 > > tracehook_notify_resume include/linux/tracehook.h:188 [inline] > > exit_to_user_mode_loop kernel/entry/common.c:140 [inline] > > exit_to_user_mode_prepare+0x195/0x1c0 kernel/entry/common.c:167 > > syscall_exit_to_user_mode+0x59/0x2b0 kernel/entry/common.c:242 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > The buggy address belongs to the object at ffff888026b66480 > > which belongs to the cache kmalloc-32 of size 32 > > The buggy address is located 0 bytes inside of > > 32-byte region [ffff888026b66480, ffff888026b664a0) > > The buggy address belongs to the page: > > page:0000000076bbbb49 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888026b66fc1 pfn:0x26b66 > > flags: 0xfffe0000000200(slab) > > raw: 00fffe0000000200 ffffea0002385208 ffffea0000782448 ffff8880aa040100 > > raw: ffff888026b66fc1 ffff888026b66000 000000010000002e 0000000000000000 > > page dumped because: kasan: bad access detected > > > > Memory state around the buggy address: > > ffff888026b66380: fa fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc > > ffff888026b66400: 00 fc fc fc fc fc fc fc 00 00 00 00 fc fc fc fc > > >ffff888026b66480: fa fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc > > ^ > > ffff888026b66500: 00 fc fc fc fc fc fc fc 00 fc fc fc fc fc fc fc > > ffff888026b66580: fa fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc > > ================================================================== > > Hard to see why file is released more than once though it's not > that hard to prepare a fix. Well, it's really the primary question why the release got called for the same file->private_data at all. Might it be a red herring, since it was caught not at the first access of pcm_oss_file in the release code path. It's referred already in the code snippet below, although the UAF got detected at a much later point (snd_pcm_oss_release_file() call)... Takashi > > --- a/sound/core/oss/pcm_oss.c > +++ b/sound/core/oss/pcm_oss.c > @@ -2535,6 +2535,10 @@ static int snd_pcm_oss_release(struct in > struct snd_pcm_oss_file *pcm_oss_file; > > pcm_oss_file = file->private_data; > + if (!pcm_oss_file) > + return 0; > + file->private_data = NULL; > + > substream = pcm_oss_file->streams[SNDRV_PCM_STREAM_PLAYBACK]; > if (substream == NULL) > substream = pcm_oss_file->streams[SNDRV_PCM_STREAM_CAPTURE]; >
