Re: sound: use-after-free in snd_timer_notify1
From: Takashi Iwai
Date: Sun Jan 31 2016 - 06:11:55 EST
On Sun, 24 Jan 2016 11:10:33 +0100,
Dmitry Vyukov wrote:
>
> Hello,
>
> The following program causes use-after-free in snd_timer_notify1:
>
> ==================================================================
> BUG: KASAN: use-after-free in snd_timer_notify1+0x411/0x460 at addr
> ffff880035a433e0
> Read of size 8 by task syz-executor/11116
> =============================================================================
> BUG kmalloc-256 (Not tainted): kasan: bad access detected
> -----------------------------------------------------------------------------
>
> INFO: Allocated in snd_timer_instance_new+0x52/0x3a0 age=1 cpu=1 pid=11106
> [< inline >] kzalloc include/linux/slab.h:607
> [< none >] snd_timer_instance_new+0x52/0x3a0 sound/core/timer.c:105
> [< none >] snd_timer_open+0x522/0xce0 sound/core/timer.c:288
> [< none >] snd_seq_timer_open+0x223/0x560
> sound/core/seq/seq_timer.c:279
> [< none >] snd_seq_queue_use+0x147/0x230
> sound/core/seq/seq_queue.c:528
> [< none >] snd_seq_queue_alloc+0x36a/0x4d0
> sound/core/seq/seq_queue.c:199
> [< none >] snd_seq_ioctl_create_queue+0xdb/0x2b0
> sound/core/seq/seq_clientmgr.c:1536
> [< none >] snd_seq_do_ioctl+0x19d/0x1c0
> sound/core/seq/seq_clientmgr.c:2209
> [< none >] snd_seq_ioctl+0x54/0xa0 sound/core/seq/seq_clientmgr.c:2224
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [< none >] do_vfs_ioctl+0x18c/0xfb0 fs/ioctl.c:674
> [< inline >] SYSC_ioctl fs/ioctl.c:689
> [< none >] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
> [< none >] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
>
> INFO: Freed in snd_timer_close+0x3a8/0x700 age=19 cpu=3 pid=11114
> [< none >] kfree+0x2b7/0x2e0 mm/slub.c:3664
> [< none >] snd_timer_close+0x3a8/0x700 sound/core/timer.c:368
> [< none >] snd_seq_timer_close+0x97/0x130
> sound/core/seq/seq_timer.c:312
> [< none >] snd_seq_queue_timer_close+0x28/0x50
> sound/core/seq/seq_queue.c:475
> [< none >] snd_seq_ioctl_set_queue_timer+0x159/0x300
> sound/core/seq/seq_clientmgr.c:1809
> [< none >] snd_seq_do_ioctl+0x19d/0x1c0
> sound/core/seq/seq_clientmgr.c:2209
> [< none >] snd_seq_ioctl+0x54/0xa0 sound/core/seq/seq_clientmgr.c:2224
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [< none >] do_vfs_ioctl+0x18c/0xfb0 fs/ioctl.c:674
> [< inline >] SYSC_ioctl fs/ioctl.c:689
> [< none >] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
> [< none >] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
>
> INFO: Slab 0xffffea0000d69000 objects=22 used=16 fp=0xffff880035a42d80
> flags=0x1fffc0000004080
> INFO: Object 0xffff880035a43330 @offset=13104 fp=0xffff880064ccee20
> CPU: 0 PID: 11116 Comm: syz-executor Tainted: G B 4.4.0+ #276
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> 00000000ffffffff ffff880064bcf560 ffffffff82999e2d ffff88003e807000
> ffff880035a43330 ffff880035a40000 ffff880064bcf590 ffffffff81757354
> ffff88003e807000 ffffea0000d69000 ffff880035a43330 ffff880064bcf718
>
> Call Trace:
> [<ffffffff817609ee>] __asan_report_load8_noabort+0x3e/0x40
> mm/kasan/report.c:295
> [<ffffffff84f40da1>] snd_timer_notify1+0x411/0x460 sound/core/timer.c:416
> [<ffffffff84f41025>] _snd_timer_stop+0x235/0x5c0 sound/core/timer.c:524
> [<ffffffff84f41d3a>] snd_timer_pause+0x1a/0x20 sound/core/timer.c:583
> [< inline >] snd_seq_timer_stop sound/core/seq/seq_timer.c:325
> [<ffffffff84fc1658>] snd_seq_timer_start+0x148/0x1a0
> sound/core/seq/seq_timer.c:366
> [< inline >] snd_seq_queue_process_event sound/core/seq/seq_queue.c:687
> [<ffffffff84fbc344>] snd_seq_control_queue+0x304/0x8b0
> sound/core/seq/seq_queue.c:748
> [<ffffffff84fc1da5>] event_input_timer+0x25/0x30
> sound/core/seq/seq_system.c:118
> [<ffffffff84fb4c14>]
> snd_seq_deliver_single_event.constprop.11+0x3f4/0x740
> sound/core/seq/seq_clientmgr.c:634
> [<ffffffff84fb5082>] snd_seq_deliver_event+0x122/0x800
> sound/core/seq/seq_clientmgr.c:828
> [<ffffffff84fb65a9>] snd_seq_dispatch_event+0xf9/0x510
> sound/core/seq/seq_clientmgr.c:902
> [<ffffffff84fba85b>] snd_seq_check_queue+0x3fb/0x560
> sound/core/seq/seq_queue.c:293
> [<ffffffff84fbac0d>] snd_seq_enqueue_event+0x24d/0x400
> sound/core/seq/seq_queue.c:357
> [<ffffffff84fb5974>] snd_seq_client_enqueue_event+0x214/0x430
> sound/core/seq/seq_clientmgr.c:961
> [<ffffffff84fb5e7f>] snd_seq_write+0x2ef/0x570
> sound/core/seq/seq_clientmgr.c:1075
> [<ffffffff817b0323>] __vfs_write+0x113/0x480 fs/read_write.c:528
> [<ffffffff817b1db7>] vfs_write+0x167/0x4a0 fs/read_write.c:577
> [< inline >] SYSC_write fs/read_write.c:624
> [<ffffffff817b50a1>] SyS_write+0x111/0x220 fs/read_write.c:616
> [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> ==================================================================
This and another report
(http://lkml.kernel.org/r/CACT4Y+ZyPRoMQjmawbvmCEDrkBD2BQuH7R09=eOkf5ESK8kJAw@xxxxxxxxxxxxxx)
took long time to figure out what went wrong, since I misinterpreted
these use-after-free reports. I expected that these are the results
of races in snd_timer*() calls. Indeed, one of these reports is
involved with it. However, the latter report isn't about the race,
although they show the very path. It is rather the linked list
corruption due to the doubled start calls.
So, below two patches are the fixes I cooked up in the end. The
second report needs only the second patch one while this report needs
both patches.
These worked for me, but it'd be appreciated to be tested more in your
side, too.
thanks,
Takashi
Attachment:
0001-ALSA-seq-Fix-yet-another-races-among-ALSA-timer-acce.patch
Description: Binary data