FAILED: patch "[PATCH] ALSA: core: Fix potential data race at fasync handling" failed to apply to 5.15-stable tree
Subsystems (2)
[email protected]
maintainerThe patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y
git checkout FETCH_HEAD
git cherry-pick -x 8146cd333d235ed32d48bb803fdf743472d7c783
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026050119-morale-scanning-6fc9@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 8146cd333d235ed32d48bb803fdf743472d7c783 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <[email protected]>
Date: Mon, 20 Apr 2026 08:17:20 +0200
Subject: [PATCH] ALSA: core: Fix potential data race at fasync handling
In snd_fasync_work_fn(), which is the offload work for traversing and processing the pending fasync list, the call of kill_fasync() is done outside the snd_fasync_lock for avoiding deadlocks. The problem is that its the references of fasync->on, fasync->signal and fasync->poll are done there also outside the lock. Since these may be modified by snd_kill_fasync() call concurrently from other process, inconsistent values might be passed to kill_fasync(). Although there shouldn't be critical UAF, it's still better to be addressed.
This patch moves the kill_fasync() argument evaluations inside the snd_fasync_lock for avoiding the data races above. The handling in fasync->on flag is optimized in the loop to skip directly.
Also, for more clarity, snd_fasync_free() takes the lock and unlink the pending entry more directly instead of clearing fasync->on flag.
sound/core/misc.c +10 -3
@@ -100,14 +100,18 @@ static LIST_HEAD(snd_fasync_list);static void snd_fasync_work_fn (struct work_struct *work) {struct snd_fasync *fasync; +int signal, poll;spin_lock_irq (&snd_fasync_lock);while (!list_empty (&snd_fasync_list)) { fasync = list_first_entry(&snd_fasync_list, struct snd_fasync, list);list_del_init (&fasync->list); +if (!fasync->on) +continue ; + signal = fasync->signal; + poll = fasync->poll;spin_unlock_irq (&snd_fasync_lock); -if (fasync->on) -kill_fasync (&fasync->fasync, fasync->signal, fasync->poll); +kill_fasync (&fasync->fasync, signal, poll);spin_lock_irq (&snd_fasync_lock); }spin_unlock_irq (&snd_fasync_lock);
@@ -158,7 +162,10 @@ void snd_fasync_free(struct snd_fasync *fasync) {if (!fasync)return ; - fasync->on =0 ; + + scoped_guard(spinlock_irq, &snd_fasync_lock) +list_del_init (&fasync->list); +flush_work (&snd_fasync_work);kfree (fasync); }
Sasha Levin
maintainerPATCH 1/1 ALSA: core: Fix potential data race at fasync handling
From: Takashi Iwai <[email protected]>
[ Upstream commit 8146cd333d235ed32d48bb803fdf743472d7c783 ]
In snd_fasync_work_fn(), which is the offload work for traversing and processing the pending fasync list, the call of kill_fasync() is done outside the snd_fasync_lock for avoiding deadlocks. The problem is that its the references of fasync->on, fasync->signal and fasync->poll are done there also outside the lock. Since these may be modified by snd_kill_fasync() call concurrently from other process, inconsistent values might be passed to kill_fasync(). Although there shouldn't be critical UAF, it's still better to be addressed.
This patch moves the kill_fasync() argument evaluations inside the snd_fasync_lock for avoiding the data races above. The handling in fasync->on flag is optimized in the loop to skip directly.
Also, for more clarity, snd_fasync_free() takes the lock and unlink the pending entry more directly instead of clearing fasync->on flag.
--- sound/core/misc.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
sound/core/misc.c +11 -3
@@ -171,14 +171,18 @@ static LIST_HEAD(snd_fasync_list);static void snd_fasync_work_fn (struct work_struct *work) {struct snd_fasync *fasync; +int signal, poll;spin_lock_irq (&snd_fasync_lock);while (!list_empty (&snd_fasync_list)) { fasync = list_first_entry(&snd_fasync_list, struct snd_fasync, list);list_del_init (&fasync->list); +if (!fasync->on) +continue ; + signal = fasync->signal; + poll = fasync->poll;spin_unlock_irq (&snd_fasync_lock); -if (fasync->on) -kill_fasync (&fasync->fasync, fasync->signal, fasync->poll); +kill_fasync (&fasync->fasync, signal, poll);spin_lock_irq (&snd_fasync_lock); }spin_unlock_irq (&snd_fasync_lock);
@@ -234,7 +238,11 @@ void snd_fasync_free(struct snd_fasync *fasync) {if (!fasync)return ; - fasync->on =0 ; + +spin_lock_irq (&snd_fasync_lock); +list_del_init (&fasync->list); +spin_unlock_irq (&snd_fasync_lock); +flush_work (&snd_fasync_work);kfree (fasync); }
Signature · 1 line
2.53.0