kernel/linux.git/sound, branch v6.6.143

ALSA: hda/hdmi: Add quirk for TUXEDO IBS14G6

2026-06-19T11:39:43+00:00

commit d649c58bcad8fb9b749e3837136a201632fa109d upstream. Depending on the timing during boot, the BIOS might report wrong pin capabilities, which can lead to HDMI audio being disabled. Therefore, force HDMI audio connection on TUXEDO InfinityBook S 14 Gen6. Signed-off-by: Aaron Erhardt Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260218213234.429686-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Werner Sembach Signed-off-by: Greg Kroah-Hartman

ALSA: firewire-motu: Protect register DSP event queue positions

2026-06-19T11:39:41+00:00

[ Upstream commit 98fb1c1bb11e29eb609b7200a25e136e05aa4498 ] The register DSP event queue is updated under parser->lock, but snd_motu_register_dsp_message_parser_count_event() reads pull_pos and push_pos without the lock. snd_motu_register_dsp_message_parser_copy_event() also reads both queue positions before taking the lock. Protect these accesses with parser->lock as well. This keeps the hwdep poll/read path consistent with the producer side and with the cached meter/parameter accessors. Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Reviewed-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260521-alsa-firewire-motu-event-locking-v1-1-708e1c2b5e56@gmail.com [ converted copy_event() from manual spin_lock_irqsave/spin_unlock_irqrestore to guard(spinlock_irqsave) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write

2026-06-19T11:39:34+00:00

commit 4790af1cc2e8871fb31f28c66e42b9a949a23992 upstream. When configuring 32 slots TDM (channels == slots == 32), the xMR (Mask Register) write used: ~0UL - ((1 << min(channels, slots)) - 1) The literal "1" is a signed 32-bit int. Shifting it by 32 positions is undefined behaviour which may set this register to 0xFFFFFFFF, masking all 32 slots. Use GENMASK_U32() macro instead. For 32 slots this produces a zero mask: ~GENMASK_U32(31, 0) = ~0xFFFFFFFF = 0x00000000 Behaviour for fewer than 32 slots is unchanged. Fixes: 770f58d7d2c5 ("ASoC: fsl_sai: Support multiple data channel enable bits") Cc: stable@vger.kernel.org Signed-off-by: Chancel Liu Reviewed-by: Shengjiu Wang Link: https://patch.msgid.link/20260601083327.1535185-1-chancel.liu@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ALSA: timer: Fix UAF at snd_timer_user_params()

2026-06-19T11:39:32+00:00

commit 053a401b592be424fea9d57c789f66cd5d8cec11 upstream. At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter. Reported-by: Kyle Zeng Tested-by: Kyle Zeng Cc: Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ASoC: wm_adsp: Fix NULL dereference when removing firmware controls

2026-06-19T11:39:29+00:00

[ Upstream commit 7d3fb78b550301e43fdc60312aed733069694426 ] In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL. Signed-off-by: Richard Fitzgerald Fixes: 0700bc2fb94c ("ASoC: wm_adsp: Separate generic cs_dsp_coeff_ctl handling") Link: https://patch.msgid.link/20260604101244.1402862-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams

2026-06-19T11:39:28+00:00

[ Upstream commit 88fe2e3658726cb21ff2dcf9770bf672f9b9d31b ] snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases. Fixes: 9b1dbd69ba6f ("ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain") Signed-off-by: Ji'an Zhou Link: https://patch.msgid.link/20260604142559.3840881-1-eilaimemedsnaimel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ASoC: qcom: q6asm-dai: do not set stream state in event and trigger callbacks

2026-06-19T11:39:19+00:00

commit cee3e63e7106c3c81b2053371fdf14240bfba2fc upstream. The q6asm-dai stream state is used by prepare() to decide whether an existing stream setup needs to be closed before opening/configuring a new one. Updating the state from trigger or asynchronous DSP callbacks can make that state stale or incorrect relative to the actual setup lifetime. In particular, setting Q6ASM_STREAM_STOPPED on STOP or EOS completion can make prepare() believe there is no active setup to close, which can result in opening/configuring the same stream more than once. Keep stream state updates tied to prepare(), where the stream is actually closed and reopened, and stop changing it from trigger and EOS callbacks. Fixes: bfbb12dfa144 ("ASoC: qcom: q6asm-dai: perform correct state check before closing") Cc: Stable@vger.kernel.org Closes: https://lore.kernel.org/all/afS7rTHdc9TyIeLx@rdacayan/ Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260518092347.3446946-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: qcom: q6asm-dai: close stream only when running

2026-06-19T11:39:19+00:00

commit 048c540ee76ded666bda74f9dae1ca3254e0633c upstream. q6asm_dai_close() and q6asm_dai_compr_free() currently issue CMD_CLOSE whenever prtd->state is non-zero. After prepare() closes an existing stream, the state is updated to Q6ASM_STREAM_STOPPED. Since this state is also non-zero, the close and free paths can send CMD_CLOSE again for a stream that has already been closed. Restrict CMD_CLOSE to the Q6ASM_STREAM_RUNNING state so the command is sent only when the ASM stream is still active. Fixes: 2a9e92d371db ("ASoC: qdsp6: q6asm: Add q6asm dai driver") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260518092347.3446946-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params

2026-06-19T11:39:18+00:00

commit 4b4db09f283df65d780bc7cee66cb4a7e9bf4770 upstream. Fix error handling in q6asm_dai_compr_set_params() and q6asm_dai_prepare() for both CMD_CLOSE and q6asm_unmap_memory_regions(). In both the functions, we are doing q6asm_audio_client_free in failure cases, which means if prepare or set_params fail, we can never recover. Now open and close are done in respective dai_open/close functions. Fixes: 2a9e92d371db ("ASoC: qdsp6: q6asm: Add q6asm dai driver") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260518092347.3446946-4-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: codecs: simple-mux: Fix enum control bounds check

2026-06-19T11:39:11+00:00

[ Upstream commit f63ad68e18d774a5d15cd7e405ead63f6b322679 ] simple_mux_control_put() rejects values greater than e->items, but enum control values are zero based. For the two-entry mux used by this driver, valid values are 0 and 1, so value 2 must be rejected as well. Accepting e->items can store an invalid mux state, pass it to the GPIO setter, and pass it on to the DAPM mux update path where it is used as an index into the enum text array. Use the same >= e->items check used by the ASoC enum helpers. Fixes: 342fbb7578d1 ("ASoC: add simple-mux") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260527-asoc-simple-mux-enum-bounds-v1-1-3f805b9fc671@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin