<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/sound/core/timer.c, branch linux-4.4.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.4.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.4.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-11-26T10:58:34+00:00</updated>
<entry>
<title>ALSA: timer: Unconditionally unlink slave instances, too</title>
<updated>2021-11-26T10:58:34+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2021-11-05T09:15:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9082aa14e202f452618f4513876f0bf086525d8e'/>
<id>urn:sha1:9082aa14e202f452618f4513876f0bf086525d8e</id>
<content type='text'>
commit ffdd98277f0a1d15a67a74ae09bee713df4c0dbc upstream.

Like the previous fix (commit c0317c0e8709 "ALSA: timer: Fix
use-after-free problem"), we have to unlink slave timer instances
immediately at snd_timer_stop(), too.  Otherwise it may leave a stale
entry in the list if the slave instance is freed before actually
running.

Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20211105091517.21733-1-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: timer: Fix use-after-free problem</title>
<updated>2021-11-26T10:58:34+00:00</updated>
<author>
<name>Wang Wensheng</name>
<email>wangwensheng4@huawei.com</email>
</author>
<published>2021-11-03T03:35:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ff7aa915782a4989a1c3aee5d879e78c2e99a624'/>
<id>urn:sha1:ff7aa915782a4989a1c3aee5d879e78c2e99a624</id>
<content type='text'>
commit c0317c0e87094f5b5782b6fdef5ae0a4b150496c upstream.

When the timer instance was add into ack_list but was not currently in
process, the user could stop it via snd_timer_stop1() without delete it
from the ack_list. Then the user could free the timer instance and when
it was actually processed UAF occurred.

This issue could be reproduced via testcase snd_timer01 in ltp - running
several instances of that testcase at the same time.

What I actually met was that the ack_list of the timer broken and the
kernel went into deadloop with irqoff. That could be detected by
hardlockup detector on board or when we run it on qemu, we could use gdb
to dump the ack_list when the console has no response.

To fix this issue, we delete the timer instance from ack_list and
active_list unconditionally in snd_timer_stop1().

Signed-off-by: Wang Wensheng &lt;wangwensheng4@huawei.com&gt;
Suggested-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20211103033517.80531-1-wangwensheng4@huawei.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: timer: Fix master timer notification</title>
<updated>2021-06-10T10:41:36+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2021-06-02T11:38:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=400d3eff06ea7e2f37c7e1d08420613541e7bacb'/>
<id>urn:sha1:400d3eff06ea7e2f37c7e1d08420613541e7bacb</id>
<content type='text'>
commit 9c1fe96bded935369f8340c2ac2e9e189f697d5d upstream.

snd_timer_notify1() calls the notification to each slave for a master
event, but it passes a wrong event number.  It should be +10 offset,
corresponding to SNDRV_TIMER_EVENT_MXXX, but it's incorrectly with
+100 offset.  Casually this was spotted by UBSAN check via syzkaller.

Reported-by: syzbot+d102fa5b35335a7e544e@syzkaller.appspotmail.com
Reviewed-by: Jaroslav Kysela &lt;perex@perex.cz&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/000000000000e5560e05c3bd1d63@google.com
Link: https://lore.kernel.org/r/20210602113823.23777-1-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: timer: Fix zero-division by continue of uninitialized instance</title>
<updated>2018-11-10T15:41:38+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-09-07T13:45:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c21f80e9661b5363638eef93be4bf8ed4fea7577'/>
<id>urn:sha1:c21f80e9661b5363638eef93be4bf8ed4fea7577</id>
<content type='text'>
[ Upstream commit 9f8a7658bcafb2a7853f7a2eae8a94e87e6e695b ]

When a user timer instance is continued without the explicit start
beforehand, the system gets eventually zero-division error like:

  divide error: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
  CPU: 1 PID: 27320 Comm: syz-executor Not tainted 4.8.0-rc3-next-20160825+ #8
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
   task: ffff88003c9b2280 task.stack: ffff880027280000
   RIP: 0010:[&lt;ffffffff858e1a6c&gt;]  [&lt;     inline     &gt;] ktime_divns include/linux/ktime.h:195
   RIP: 0010:[&lt;ffffffff858e1a6c&gt;]  [&lt;ffffffff858e1a6c&gt;] snd_hrtimer_callback+0x1bc/0x3c0 sound/core/hrtimer.c:62
  Call Trace:
   &lt;IRQ&gt;
   [&lt;     inline     &gt;] __run_hrtimer kernel/time/hrtimer.c:1238
   [&lt;ffffffff81504335&gt;] __hrtimer_run_queues+0x325/0xe70 kernel/time/hrtimer.c:1302
   [&lt;ffffffff81506ceb&gt;] hrtimer_interrupt+0x18b/0x420 kernel/time/hrtimer.c:1336
   [&lt;ffffffff8126d8df&gt;] local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:933
   [&lt;ffffffff86e13056&gt;] smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:957
   [&lt;ffffffff86e1210c&gt;] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:487
   &lt;EOI&gt;
   .....

Although a similar issue was spotted and a fix patch was merged in
commit [6b760bb2c63a: ALSA: timer: fix division by zero after
SNDRV_TIMER_IOCTL_CONTINUE], it seems covering only a part of
iceberg.

In this patch, we fix the issue a bit more drastically.  Basically the
continue of an uninitialized timer is supposed to be a fresh start, so
we do it for user timers.  For the direct snd_timer_continue() call,
there is no way to pass the initial tick value, so we kick out for the
uninitialized case.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ALSA: timer: Fix pause event notification</title>
<updated>2018-05-30T05:48:51+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben.hutchings@codethink.co.uk</email>
</author>
<published>2018-05-17T21:34:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c04a69fb83974aa25f1065fc0c7b63e046dc46f2'/>
<id>urn:sha1:c04a69fb83974aa25f1065fc0c7b63e046dc46f2</id>
<content type='text'>
commit 3ae180972564846e6d794e3615e1ab0a1e6c4ef9 upstream.

Commit f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock")
combined the start/continue and stop/pause functions, and in doing so
changed the event code for the pause case to SNDRV_TIMER_EVENT_CONTINUE.
Change it back to SNDRV_TIMER_EVENT_PAUSE.

Fixes: f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock")
Signed-off-by: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: timer: Call notifier in the same spinlock</title>
<updated>2018-05-26T06:48:49+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-02-10T11:47:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bea8a671cee74232bbeef3980354cb9b305f6a9f'/>
<id>urn:sha1:bea8a671cee74232bbeef3980354cb9b305f6a9f</id>
<content type='text'>
commit f65e0d299807d8a11812845c972493c3f9a18e10 upstream.

snd_timer_notify1() is called outside the spinlock and it retakes the
lock after the unlock.  This is rather racy, and it's safer to move
snd_timer_notify() call inside the main spinlock.

The patch also contains a slight refactoring / cleanup of the code.
Now all start/stop/continue/pause look more symmetric and a bit better
readable.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: timer: Fix missing queue indices reset at SNDRV_TIMER_IOCTL_SELECT</title>
<updated>2017-06-14T11:16:26+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-02T15:26:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54d12fbf54d4d40d2a47200150344bc001a29e96'/>
<id>urn:sha1:54d12fbf54d4d40d2a47200150344bc001a29e96</id>
<content type='text'>
commit ba3021b2c79b2fa9114f92790a99deb27a65b728 upstream.

snd_timer_user_tselect() reallocates the queue buffer dynamically, but
it forgot to reset its indices.  Since the read may happen
concurrently with ioctl and snd_timer_user_tselect() allocates the
buffer via kmalloc(), this may lead to the leak of uninitialized
kernel-space data, as spotted via KMSAN:

  BUG: KMSAN: use of unitialized 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

This patch adds the missing reset of queue indices.  Together with the
previous fix for the ioctl/read race, we cover the whole problem.

Reported-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: timer: Fix race between read and ioctl</title>
<updated>2017-06-14T11:16:26+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-02T13:03:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f5bc918760c8100410847a6a6e4c25f24e358e0c'/>
<id>urn:sha1:f5bc918760c8100410847a6a6e4c25f24e358e0c</id>
<content type='text'>
commit d11662f4f798b50d8c8743f433842c3e40fe3378 upstream.

The read from ALSA timer device, the function snd_timer_user_tread(),
may access to an uninitialized struct snd_timer_user fields when the
read is concurrently performed while the ioctl like
snd_timer_user_tselect() is invoked.  We have already fixed the races
among ioctls via a mutex, but we seem to have forgotten the race
between read vs ioctl.

This patch simply applies (more exactly extends the already applied
range of) tu-&gt;ioctl_lock in snd_timer_user_tread() for closing the
race window.

Reported-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: timer: Reject user params with too small ticks</title>
<updated>2017-03-12T05:37:24+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-02-28T13:49:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9879f9d01a3c608f75596437f2c4ae4b218da9dd'/>
<id>urn:sha1:9879f9d01a3c608f75596437f2c4ae4b218da9dd</id>
<content type='text'>
commit 71321eb3f2d0df4e6c327e0b936eec4458a12054 upstream.

When a user sets a too small ticks with a fine-grained timer like
hrtimer, the kernel tries to fire up the timer irq too frequently.
This may lead to the condensed locks, eventually the kernel spinlock
lockup with warnings.

For avoiding such a situation, we define a lower limit of the
resolution, namely 1ms.  When the user passes a too small tick value
that results in less than that, the kernel returns -EINVAL now.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: timer: fix NULL pointer dereference on memory allocation failure</title>
<updated>2016-09-15T06:27:54+00:00</updated>
<author>
<name>Vegard Nossum</name>
<email>vegard.nossum@oracle.com</email>
</author>
<published>2016-08-28T22:33:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f5b004e4edb87ea4c0a72a72191f33d372d08251'/>
<id>urn:sha1:f5b004e4edb87ea4c0a72a72191f33d372d08251</id>
<content type='text'>
commit 8ddc05638ee42b18ba4fe99b5fb647fa3ad20456 upstream.

I hit this with syzkaller:

    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    task: ffff88011278d600 task.stack: ffff8801120c0000
    RIP: 0010:[&lt;ffffffff82c8ba07&gt;]  [&lt;ffffffff82c8ba07&gt;] snd_hrtimer_start+0x77/0x100
    RSP: 0018:ffff8801120c7a60  EFLAGS: 00010006
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007
    RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048
    RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790
    R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980
    R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286
    FS:  00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0
    Stack:
     ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0
     ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000
     ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0
    Call Trace:
     [&lt;ffffffff82c81ab1&gt;] snd_timer_start1+0x331/0x670
     [&lt;ffffffff82c85bfd&gt;] snd_timer_start+0x5d/0xa0
     [&lt;ffffffff82c8795e&gt;] snd_timer_user_ioctl+0x88e/0x2830
     [&lt;ffffffff8159f3a0&gt;] ? __follow_pte.isra.49+0x430/0x430
     [&lt;ffffffff82c870d0&gt;] ? snd_timer_pause+0x80/0x80
     [&lt;ffffffff815a26fa&gt;] ? do_wp_page+0x3aa/0x1c90
     [&lt;ffffffff8132762f&gt;] ? put_prev_entity+0x108f/0x21a0
     [&lt;ffffffff82c870d0&gt;] ? snd_timer_pause+0x80/0x80
     [&lt;ffffffff816b0733&gt;] do_vfs_ioctl+0x193/0x1050
     [&lt;ffffffff813510af&gt;] ? cpuacct_account_field+0x12f/0x1a0
     [&lt;ffffffff816b05a0&gt;] ? ioctl_preallocate+0x200/0x200
     [&lt;ffffffff81002f2f&gt;] ? syscall_trace_enter+0x3cf/0xdb0
     [&lt;ffffffff815045ba&gt;] ? __context_tracking_exit.part.4+0x9a/0x1e0
     [&lt;ffffffff81002b60&gt;] ? exit_to_usermode_loop+0x190/0x190
     [&lt;ffffffff82001a97&gt;] ? check_preemption_disabled+0x37/0x1e0
     [&lt;ffffffff81d93889&gt;] ? security_file_ioctl+0x89/0xb0
     [&lt;ffffffff816b167f&gt;] SyS_ioctl+0x8f/0xc0
     [&lt;ffffffff816b15f0&gt;] ? do_vfs_ioctl+0x1050/0x1050
     [&lt;ffffffff81005524&gt;] do_syscall_64+0x1c4/0x4e0
     [&lt;ffffffff83c32b2a&gt;] entry_SYSCALL64_slow_path+0x25/0x25
    Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46
    RIP  [&lt;ffffffff82c8ba07&gt;] snd_hrtimer_start+0x77/0x100
     RSP &lt;ffff8801120c7a60&gt;
    ---[ end trace 5955b08db7f2b029 ]---

This can happen if snd_hrtimer_open() fails to allocate memory and
returns an error, which is currently not checked by snd_timer_open():

    ioctl(SNDRV_TIMER_IOCTL_SELECT)
     - snd_timer_user_tselect()
	- snd_timer_close()
	   - snd_hrtimer_close()
	      - (struct snd_timer *) t-&gt;private_data = NULL
        - snd_timer_open()
           - snd_hrtimer_open()
              - kzalloc() fails; t-&gt;private_data is still NULL

    ioctl(SNDRV_TIMER_IOCTL_START)
     - snd_timer_user_start()
	- snd_timer_start()
	   - snd_timer_start1()
	      - snd_hrtimer_start()
		- t-&gt;private_data == NULL // boom

Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
