kernel/linux.git/sound/core/timer.c, branch v5.10.257

ALSA: timer: Relax start tick time check for slave timer elements

2024-09-04T11:17:43+00:00

commit ccbfcac05866ebe6eb3bc6d07b51d4ed4fcde436 upstream. The recent addition of a sanity check for a too low start tick time seems breaking some applications that uses aloop with a certain slave timer setup. They may have the initial resolution 0, hence it's treated as if it were a too low value. Relax and skip the check for the slave timer instance for addressing the regression. Fixes: 4a63bd179fa8 ("ALSA: timer: Set lower bound of start tick time") Cc: Link: https://github.com/raspberrypi/linux/issues/6294 Link: https://patch.msgid.link/20240810084833.10939-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: timer: Set lower bound of start tick time

2024-06-16T11:32:30+00:00

commit 4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e upstream. Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer. This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow. Reported-by: syzbot+43120c2af6ca2938cc38@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/000000000000fa00a1061740ab6d@google.com Cc: Link: https://lore.kernel.org/r/20240514182745.4015-1-tiwai@suse.de Signed-off-by: Takashi Iwai [ backport note: the error handling is changed, as the original commit is based on the recent cleanup with guard() in commit beb45974dd49 -- tiwai ] Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: timer: Use deferred fasync helper

2022-08-25T09:38:20+00:00

[ Upstream commit 95cc637c1afd83fb7dd3d7c8a53710488f4caf9c ] For avoiding the potential deadlock via kill_fasync() call, use the new fasync helpers to defer the invocation from PCI API. Note that it's merely a workaround. Reported-by: syzbot+1ee0910eca9c94f71f25@syzkaller.appspotmail.com Reported-by: syzbot+49b10793b867871ee26f@syzkaller.appspotmail.com Reported-by: syzbot+8285e973a41b5aa68902@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20220728125945.29533-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: timer: Unconditionally unlink slave instances, too

2021-11-18T13:03:40+00:00

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: Link: https://lore.kernel.org/r/20211105091517.21733-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: timer: Fix use-after-free problem

2021-11-18T13:03:40+00:00

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 Suggested-by: Takashi Iwai Cc: Link: https://lore.kernel.org/r/20211103033517.80531-1-wangwensheng4@huawei.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: timer: Fix master timer notification

2021-06-10T11:39:25+00:00

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 Cc: 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 Signed-off-by: Greg Kroah-Hartman

ALSA: timer: Replace tasklet with work

2020-09-09T16:32:52+00:00

The tasklet is an old API that should be deprecated, usually can be converted to another decent API. In ALSA core timer API, the callbacks can be offlined to a tasklet when a flag is set in the timer backend. It can be achieved gracefully with a work queued in the high-prio system workqueue. This patch replaces the usage of tasklet in ALSA timer API with a simple work. Currently the tasklet feature is used only in the system timer and hrtimer backends, so both are patched to use the new flag name SNDRV_TIMER_HW_WORK, too. Link: https://lore.kernel.org/r/20200903104131.21097-3-tiwai@suse.de Signed-off-by: Takashi Iwai

Merge branch 'for-linus' into for-next

2020-09-09T16:26:48+00:00

Back-merge to apply the tasklet conversion patches that are based on the already applied tasklet API changes on 5.9-rc4. Signed-off-by: Takashi Iwai

ALSA: core: timer: clarify operator precedence

2020-09-03T07:25:26+00:00

fix cppcheck warning: sound/core/timer.c:1286:9: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] ? "running" : "stopped"); ^ Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200902212133.30964-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai

ALSA: core: timer: remove redundant assignment

2020-09-03T07:25:16+00:00

Cppcheck complains about a possible NULL pointer dereference but it actually looks like the NULL assignment is not needed (same loop is used in other parts of the file without it). Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200902212133.30964-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai