oss-security - Linux kernel 2.6.0 to 4.12-rc4 infoleak due to a data race in ALSA timer

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAG_fn=W+kiQAmmtXeEwECmyabiJwaEQVyxo0D29-PTXwzgF9jg@mail.gmail.com>
Date: Mon, 12 Jun 2017 19:27:51 +0200
From: Alexander Potapenko <glider@...gle.com>
To: oss-security@...ts.openwall.com
Cc: Dmitriy Vyukov <dvyukov@...gle.com>, Kostya Serebryany <kcc@...gle.com>, Takashi Iwai <tiwai@...e.de>, 
	Andrey Konovalov <andreyknvl@...gle.com>
Subject: Linux kernel 2.6.0 to 4.12-rc4 infoleak due to a data race in ALSA timer

Hi all,

Until recently, /dev/snd/timer driver was prone to a data race, which
led to uninitialized memory from the kernel heap being copied to the
userspace.
KernelMemorySanitizer (http://github.com/google/kmsan) reported it as
follows (line numbers relative to 4.11-rc5):

==================================================================
BUG: KMSAN: use of uninitialized memory in snd_timer_user_read+0x6c4/0xa10
CPU: 0 PID: 1037 Comm: probe Not tainted 4.11.0-rc5+ #2739
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x143/0x1b0 lib/dump_stack.c:52
 kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
 kmsan_check_memory+0xc2/0x140 mm/kmsan/kmsan.c:1086
 copy_to_user ./arch/x86/include/asm/uaccess.h:725
 snd_timer_user_read+0x6c4/0xa10 sound/core/timer.c:2004
 do_loop_readv_writev fs/read_write.c:716
 __do_readv_writev+0x94c/0x1380 fs/read_write.c:864
 do_readv_writev fs/read_write.c:894
 vfs_readv fs/read_write.c:908
 do_readv+0x52a/0x5d0 fs/read_write.c:934
 SYSC_readv+0xb6/0xd0 fs/read_write.c:1021
 SyS_readv+0x87/0xb0 fs/read_write.c:1018
 entry_SYSCALL_64_fastpath+0x13/0x94 arch/x86/entry/entry_64.S:204
RIP: 0033:0x43fb70
RSP: 002b:00007f736e41a930 EFLAGS: 00000293 ORIG_RAX: 0000000000000013
RAX: ffffffffffffffda RBX: 00007f736e41b700 RCX: 000000000043fb70
RDX: 0000000000000001 RSI: 00007f736e41a980 RDI: 0000000000000003
RBP: 00007ffe39b29920 R08: 0000000000000000 R09: 00007f736e41b700
R10: 00007f736e41b9d0 R11: 0000000000000293 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f736e41b9c0 R15: 00007f736e41b700
origin: 00000000b2800057
 save_stack_trace+0x59/0x60 arch/x86/kernel/stacktrace.c:59
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:352
 kmsan_internal_poison_shadow+0xb1/0x1a0 mm/kmsan/kmsan.c:247
 kmsan_kmalloc+0x7f/0xe0 mm/kmsan/kmsan.c:387
 __kmalloc+0x1bb/0x260 mm/slub.c:3788
 kmalloc ./include/linux/slab.h:495
 snd_timer_user_tselect sound/core/timer.c:1636
 __snd_timer_user_ioctl sound/core/timer.c:1914
 snd_timer_user_ioctl+0x2c46/0x5af0 sound/core/timer.c:1944
 vfs_ioctl fs/ioctl.c:45
 do_vfs_ioctl+0xa8e/0x2060 fs/ioctl.c:685
 SYSC_ioctl+0x20d/0x2a0 fs/ioctl.c:700
 SyS_ioctl+0x87/0xb0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x13/0x94 arch/x86/entry/entry_64.S:204
==================================================================

The above means that the heap buffer allocated in
snd_timer_user_tselect() while handling ioctl(fd,
SNDRV_TIMER_IOCTL_SELECT, ...) sometimes remains uninitialized till
it's being copied to user space by a readv() call.

The bug allows a local user having access to /dev/snd/timer to sniff
data belonging to other users, if that data was previously copied to
the kernel space.

Takashi Iwai has fixed the issue in the upstream kernel in the
following commits:
https://github.com/torvalds/linux/commit/d11662f4f798b50d8c8743f433842c3e40fe3378
https://github.com/torvalds/linux/commit/ba3021b2c79b2fa9114f92790a99deb27a65b728

I'll be disclosing the PoC exploit for this bug on Tuesday, June 20,
16:00 CEST, unless other exploits for the same issue appear earlier.

-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.