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. [ backport note: the error handling is changed, as the original commit is based on the recent cleanup with guard() in commit beb45974dd49 -- tiwai ] Reported-by: syzbot+43120c2af6ca2938cc38@xxxxxxxxxxxxxxxxxxxxxxxxx Closes: https://lore.kernel.org/r/000000000000fa00a1061740ab6d@xxxxxxxxxx Cc: <stable@xxxxxxxxxxxxxxx> Link: https://lore.kernel.org/r/20240514182745.4015-1-tiwai@xxxxxxx Signed-off-by: Takashi Iwai <tiwai@xxxxxxx> --- Greg, this is an alternative fix to the original cherry-pick; apply to 6.8.y and older stable kernels. Thanks! sound/core/timer.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sound/core/timer.c b/sound/core/timer.c index e6e551d4a29e..a0b515981ee9 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -553,6 +553,16 @@ static int snd_timer_start1(struct snd_timer_instance *timeri, goto unlock; } + /* check the actual time for the start tick; + * bail out as error if it's way too low (< 100us) + */ + if (start) { + if ((u64)snd_timer_hw_resolution(timer) * ticks < 100000) { + result = -EINVAL; + goto unlock; + } + } + if (start) timeri->ticks = timeri->cticks = ticks; else if (!timeri->cticks) -- 2.43.0
