kernel.git/sound/core/timer.c, branch linux-6.9.y

ALSA: timer: Set lower bound of start tick time

2024-05-30T07:44:03Z

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

ALSA: timer: Fix missing irq-disable at closing

2024-03-15T10:16:47Z

The conversion to guard macro dropped the irq-disablement at closing mistakenly, which may lead to a race. Fix it. Fixes: beb45974dd49 ("ALSA: timer: Use guard() for locking") Reported-by: syzbot+28c1a5a5b041a754b947@syzkaller.appspotmail.com Closes: http://lore.kernel.org/r/0000000000000b9a510613b0145f@google.com Message-ID: <20240315101447.18395-1-tiwai@suse.de> Signed-off-by: Takashi Iwai

ALSA: timer: Use guard() for locking

2024-02-28T14:01:20Z

We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. For making changes easier, some functions widen the application of register_mutex, but those shouldn't influence on any actual performance. Also, one code block was factored out as a function so that guard() can be applied cleanly without much indentation. There are still a few remaining explicit spin_lock/unlock calls, and those are for the places where we do temporary unlock/relock, which doesn't fit well with the guard(), so far. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20240227085306.9764-4-tiwai@suse.de

ALSA: timer: Use automatic cleanup of kfree()

2024-02-23T09:57:30Z

There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20240222111509.28390-5-tiwai@suse.de

ALSA: timer: Create device with snd_device_alloc()

2023-08-17T07:24:21Z

Align with the other components, and use snd_device_alloc() for the new sound device for timer, too. No functional changes. Reviewed-by: Jaroslav Kysela Signed-off-by: Curtis Malainey Tested-by: Curtis Malainey Link: https://lore.kernel.org/r/20230816160252.23396-8-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: timer: minimize open-coded access to hw.resolution

2023-06-13T05:43:38Z

Some info-querying code still used hw.resolution directly instead of calling snd_timer_hw_resolution(), thus missing a possible hw.c_resolution callback. This patch rectifies that. Signed-off-by: Oswald Buddenhagen Link: https://lore.kernel.org/r/20230612191325.1315854-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai

ALSA: timer: Use deferred fasync helper

2022-07-29T10:57:11Z

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

ALSA: timer: Unconditionally unlink slave instances, too

2021-11-05T10:27:27Z

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

ALSA: timer: Fix use-after-free problem

2021-11-03T15:52:13Z

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

ALSA: timer: Fix master timer notification

2021-06-03T07:39:58Z

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