[alsa-devel] KASAN: use-after-free in loopback_active_get
We report the crash: KASAN: use-after-free in loopback_active_get
This crash has been found in v4.17-rc1 using RaceFuzzer (a modified version of Syzkaller), which we describe more at the end of this report. Our analysis shows that the race occurs when invoking two syscalls concurrently, ioctl$SNDRV_CTL_IOCTL_ELEM_READ and syz_open_dev$audion.
kernel config: https://kiwi.cs.purdue.ed/static/race-fuzzer/KASAN_use-after-free_in_loopbac...
Analysis:
When there is a race between sound/drivers/aloop.c:895 (loopback_active_get) and sound/drivers/aloop.c:678 (free_cable), the retrieved cable pointer in loopback_active_get() may point to the freed memory region. When loopback_active_get() dereferences this pointer, use-after-free occurs.
Possible CPU execution:
CPU0 CPU1 loopback_active_get() free_cable() ---- ---- struct loopback_cable *cable = ... loopback->cables[substream->number][dev] = NULL; kfree(cable); cable->running <-- Use-after-free
Call Sequence: CPU0 loopback_active_get snd_ctl_elem_read snd_ctl_elem_read_user snd_ctl_ioctl
CPU1 free_cable loopback_close snd_pcm_release_substream snd_pcm_release_substream snd_pcm_oss_release_file snd_pcm_oss_release_file snd_pcm_oss_release
We observed that snd_pcm_oss_release() is called during the open("/dev/audio1") syscall. In our configuration, the function do_dentry_open() returns -EINVAL since below if statement is evaluated as true. if ((f->f_flags & O_DIRECT) (!f->f_mapping->a_ops || !f->f_mapping->a_ops->direct_IO)) Therefore, fput() is called and snd_pcm_oss_release() is called as a pending work before returning to the user space. But we suspect that the insufficient locking between snd_ctl_ioctl() and snd_pcm_oss_release(), not the vfs_layer, is the cause of the crash.
-------- Read of size 4 at addr ffff88023aa4899c by task syz-executor0/27703
CPU: 0 PID: 27703 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x182/0x24c lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] __asan_load4+0x78/0x80 mm/kasan/kasan.c:698 loopback_active_get+0x71/0xb0 sound/drivers/aloop.c:900 snd_ctl_elem_read+0x14e/0x190 sound/core/control.c:896 snd_ctl_elem_read_user sound/core/control.c:914 [inline] snd_ctl_ioctl+0xaf7/0xce0 sound/core/control.c:1560 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:500 [inline] do_vfs_ioctl+0x179/0xf40 fs/ioctl.c:684 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701 __do_sys_ioctl fs/ioctl.c:708 [inline] __se_sys_ioctl fs/ioctl.c:706 [inline] __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:706 do_syscall_64+0x17a/0x530 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x453bc9 RSP: 002b:00007fc5fba5eaf8 EFLAGS: 00000212 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000708020 RCX: 0000000000453bc9 RDX: 0000000020003b38 RSI: 00000000c4c85512 RDI: 0000000000000005 RBP: 00000000000025a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000212 R12: 00000000004aed78 R13: 00000000ffffffff R14: 0000000000000005 R15: 00000000c4c85512
Allocated by task 27704: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620 kmalloc include/linux/slab.h:512 [inline] kzalloc include/linux/slab.h:701 [inline] loopback_open+0x4d2/0x720 sound/drivers/aloop.c:704 snd_pcm_open_substream+0x174/0x250 sound/core/pcm_native.c:2391 snd_pcm_oss_open_file sound/core/oss/pcm_oss.c:2423 [inline] snd_pcm_oss_open+0x799/0xfc0 sound/core/oss/pcm_oss.c:2505 soundcore_open+0x2db/0x3e0 sound/sound_core.c:597 chrdev_open+0x1c6/0x450 fs/char_dev.c:417 do_dentry_open+0x520/0x7c0 fs/open.c:784 vfs_open+0xc5/0x120 fs/open.c:906 do_last fs/namei.c:3365 [inline] path_openat+0x1133/0x31a0 fs/namei.c:3501 do_filp_open+0x15a/0x1e0 fs/namei.c:3535 do_sys_open+0x464/0x540 fs/open.c:1093 __do_sys_open fs/open.c:1111 [inline] __se_sys_open fs/open.c:1106 [inline] __x64_sys_open+0x4c/0x60 fs/open.c:1106 do_syscall_64+0x17a/0x530 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 27704: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xd9/0x260 mm/slab.c:3813 free_cable+0x148/0x160 sound/drivers/aloop.c:679 loopback_close+0x63/0x80 sound/drivers/aloop.c:766 snd_pcm_release_substream.part.46+0x10e/0x1b0 sound/core/pcm_native.c:2357 snd_pcm_release_substream+0x49/0x60 sound/core/pcm_native.c:2349 snd_pcm_oss_release_file.part.23+0x50/0x70 sound/core/oss/pcm_oss.c:2382 snd_pcm_oss_release_file sound/core/oss/pcm_oss.c:2377 [inline] snd_pcm_oss_release+0xa9/0x160 sound/core/oss/pcm_oss.c:2562 __fput+0x246/0x4f0 fs/file_table.c:209 ____fput+0x15/0x20 fs/file_table.c:243 task_work_run+0x1b6/0x220 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:191 [inline] exit_to_usermode_loop+0x28d/0x290 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] syscall_return_slowpath arch/x86/entry/common.c:265 [inline] do_syscall_64+0x51a/0x530 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff88023aa48900 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 156 bytes inside of 192-byte region [ffff88023aa48900, ffff88023aa489c0) The buggy address belongs to the page: page:ffffea0008ea9200 count:1 mapcount:0 mapping:ffff88023aa48000 index:0x0 flags: 0x6fffc0000000100(slab) raw: 06fffc0000000100 ffff88023aa48000 0000000000000000 0000000100000010 raw: ffffea0008eceb60 ffffea0008d95960 ffff8800b6800040 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff88023aa48880: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff88023aa48900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88023aa48980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^ ffff88023aa48a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88023aa48a80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ==================================================================
= About RaceFuzzer
RaceFuzzer is a customized version of Syzkaller, specifically tailored to find race condition bugs in the Linux kernel. While we leverage many different technique, the notable feature of RaceFuzzer is in leveraging a custom hypervisor (QEMU/KVM) to interleave the scheduling. In particular, we modified the hypervisor to intentionally stall a per-core execution, which is similar to supporting per-core breakpoint functionality. This allows RaceFuzzer to force the kernel to deterministically trigger racy condition (which may rarely happen in practice due to randomness in scheduling).
RaceFuzzer's C repro always pinpoints two racy syscalls. Since C repro's scheduling synchronization should be performed at the user space, its reproducibility is limited (reproduction may take from 1 second to 10 minutes (or even more), depending on a bug). This is because, while RaceFuzzer precisely interleaves the scheduling at the kernel's instruction level when finding this bug, C repro cannot fully utilize such a feature. Please disregard all code related to "should_hypercall" in the C repro, as this is only for our debugging purposes using our own hypervisor.
On Mon, 30 Apr 2018 09:53:14 +0200, DaeRyong Jeong wrote:
We report the crash: KASAN: use-after-free in loopback_active_get
This crash has been found in v4.17-rc1 using RaceFuzzer (a modified version of Syzkaller), which we describe more at the end of this report. Our analysis shows that the race occurs when invoking two syscalls concurrently, ioctl$SNDRV_CTL_IOCTL_ELEM_READ and syz_open_dev$audion.
kernel config: https://kiwi.cs.purdue.ed/static/race-fuzzer/KASAN_use-after-free_in_loopbac...
Analysis:
When there is a race between sound/drivers/aloop.c:895 (loopback_active_get) and sound/drivers/aloop.c:678 (free_cable), the retrieved cable pointer in loopback_active_get() may point to the freed memory region. When loopback_active_get() dereferences this pointer, use-after-free occurs.
Possible CPU execution:
CPU0 CPU1 loopback_active_get() free_cable()
struct loopback_cable *cable = ... loopback->cables[substream->number][dev] = NULL; kfree(cable); cable->running <-- Use-after-free
Call Sequence: CPU0 loopback_active_get snd_ctl_elem_read snd_ctl_elem_read_user snd_ctl_ioctl
CPU1 free_cable loopback_close snd_pcm_release_substream snd_pcm_release_substream snd_pcm_oss_release_file snd_pcm_oss_release_file snd_pcm_oss_release
We observed that snd_pcm_oss_release() is called during the open("/dev/audio1") syscall. In our configuration, the function do_dentry_open() returns -EINVAL since below if statement is evaluated as true. if ((f->f_flags & O_DIRECT) (!f->f_mapping->a_ops || !f->f_mapping->a_ops->direct_IO)) Therefore, fput() is called and snd_pcm_oss_release() is called as a pending work before returning to the user space. But we suspect that the insufficient locking between snd_ctl_ioctl() and snd_pcm_oss_release(), not the vfs_layer, is the cause of the crash.
Right, it must be a race between ALSA ctl API ioctl access and the PCM release. It's irrelevant with whether it's a delayed release or not, but just a simple fact that it misses the loopback->cable_lock at accessing.
The patch below should fix the issue. Could you check it?
thanks,
Takashi
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: aloop: Add missing cable lock to ctl API callbacks
Some control API callbacks in aloop driver are too lazy to take the loopback->cable_lock and it results in possible races of cable access while it's being freed. It eventually lead to a UAF, as reported by fuzzer recently.
This patch covers such control API callbacks and add the proper mutex locks.
Reported-by: DaeRyong Jeong threeearcat@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/drivers/aloop.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c index 58e349fc893f..eab7f594ebe7 100644 --- a/sound/drivers/aloop.c +++ b/sound/drivers/aloop.c @@ -831,9 +831,11 @@ static int loopback_rate_shift_get(struct snd_kcontrol *kcontrol, { struct loopback *loopback = snd_kcontrol_chip(kcontrol); + mutex_lock(&loopback->cable_lock); ucontrol->value.integer.value[0] = loopback->setup[kcontrol->id.subdevice] [kcontrol->id.device].rate_shift; + mutex_unlock(&loopback->cable_lock); return 0; }
@@ -865,9 +867,11 @@ static int loopback_notify_get(struct snd_kcontrol *kcontrol, { struct loopback *loopback = snd_kcontrol_chip(kcontrol); + mutex_lock(&loopback->cable_lock); ucontrol->value.integer.value[0] = loopback->setup[kcontrol->id.subdevice] [kcontrol->id.device].notify; + mutex_unlock(&loopback->cable_lock); return 0; }
@@ -879,12 +883,14 @@ static int loopback_notify_put(struct snd_kcontrol *kcontrol, int change = 0;
val = ucontrol->value.integer.value[0] ? 1 : 0; + mutex_lock(&loopback->cable_lock); if (val != loopback->setup[kcontrol->id.subdevice] [kcontrol->id.device].notify) { loopback->setup[kcontrol->id.subdevice] [kcontrol->id.device].notify = val; change = 1; } + mutex_unlock(&loopback->cable_lock); return change; }
@@ -892,15 +898,18 @@ static int loopback_active_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct loopback *loopback = snd_kcontrol_chip(kcontrol); - struct loopback_cable *cable = loopback->cables - [kcontrol->id.subdevice][kcontrol->id.device ^ 1]; + struct loopback_cable *cable; + unsigned int val = 0;
+ mutex_lock(&loopback->cable_lock); + cable = loopback->cables[kcontrol->id.subdevice][kcontrol->id.device ^ 1]; if (cable != NULL) { unsigned int running = cable->running ^ cable->pause;
val = (running & (1 << SNDRV_PCM_STREAM_PLAYBACK)) ? 1 : 0; } + mutex_unlock(&loopback->cable_lock); ucontrol->value.integer.value[0] = val; return 0; } @@ -943,9 +952,11 @@ static int loopback_rate_get(struct snd_kcontrol *kcontrol, { struct loopback *loopback = snd_kcontrol_chip(kcontrol); + mutex_lock(&loopback->cable_lock); ucontrol->value.integer.value[0] = loopback->setup[kcontrol->id.subdevice] [kcontrol->id.device].rate; + mutex_unlock(&loopback->cable_lock); return 0; }
@@ -965,9 +976,11 @@ static int loopback_channels_get(struct snd_kcontrol *kcontrol, { struct loopback *loopback = snd_kcontrol_chip(kcontrol); + mutex_lock(&loopback->cable_lock); ucontrol->value.integer.value[0] = loopback->setup[kcontrol->id.subdevice] [kcontrol->id.device].channels; + mutex_unlock(&loopback->cable_lock); return 0; }
participants (2)
-
DaeRyong Jeong -
Takashi Iwai