<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/sound, branch v6.18.36</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-19T11:44:07+00:00</updated>
<entry>
<title>ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write</title>
<updated>2026-06-19T11:44:07+00:00</updated>
<author>
<name>Chancel Liu</name>
<email>chancel.liu@nxp.com</email>
</author>
<published>2026-06-01T08:33:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6f72b902c34d6c18bbb7d5a38898d5e198a4d743'/>
<id>urn:sha1:6f72b902c34d6c18bbb7d5a38898d5e198a4d743</id>
<content type='text'>
commit 4790af1cc2e8871fb31f28c66e42b9a949a23992 upstream.

When configuring 32 slots TDM (channels == slots == 32), the xMR
(Mask Register) write used:
~0UL - ((1 &lt;&lt; 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 &lt;chancel.liu@nxp.com&gt;
Reviewed-by: Shengjiu Wang &lt;shengjiu.wang@gmail.com&gt;
Link: https://patch.msgid.link/20260601083327.1535185-1-chancel.liu@oss.nxp.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: timer: Fix UAF at snd_timer_user_params()</title>
<updated>2026-06-19T11:44:04+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2026-06-06T16:11:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3d39da65b5c422c5e5afb7d5651b0698d060a827'/>
<id>urn:sha1:3d39da65b5c422c5e5afb7d5651b0698d060a827</id>
<content type='text'>
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 &lt;kylebot@openai.com&gt;
Tested-by: Kyle Zeng &lt;kylebot@openai.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: timer: Forcibly close timer instances at closing</title>
<updated>2026-06-19T11:44:04+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2026-06-06T16:11:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f46093dd22969037beb1fce2e043f3236be41c92'/>
<id>urn:sha1:f46093dd22969037beb1fce2e043f3236be41c92</id>
<content type='text'>
commit da3039e91d1f835874ed6e9a33ea19ee80c2cb92 upstream.

When snd_timer object is freed via snd_timer_free() and still pending
snd_timer_instance objects are assigned to the timer object, it tries
to unlink all instances and just set NULL to each ti-&gt;timer, then
releases the resources immediately.  The problem is, however, when
there are slave timer instances that are associated with a master
instance linked to this timer: namely, those slave instances still
point to the freed timer object although the master instance is
unlinked, which may lead to user-after-free.  The bug can be easily
triggered particularly when a new userspace-driven timers
(CONFIG_SND_UTIMER) is involved, since it can create and delete the
timer object via a simple file open/close, while the other
applications may keep accessing to that timer.

This patch is an attempt to paper over the problem above: now instead
of just unlinking, call snd_timer_close[_locked]() forcibly for each
pending timer instance, so that all assigned slave timer instances are
properly detached, too.  Since snd_timer_close() might be called later
by the driver that created that instance, the check of
SNDRV_TIMER_IFLG_DEAD is added at the beginning, too.

Reported-by: Kyle Zeng &lt;kylebot@openai.com&gt;
Tested-by: Kyle Zeng &lt;kylebot@openai.com&gt;
Fixes: 37745918e0e7 ("ALSA: timer: Introduce virtual userspace-driven timers")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260606161145.1933447-1-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ASoC: SOF: amd: fix for ipc flags check</title>
<updated>2026-06-19T11:43:59+00:00</updated>
<author>
<name>Vijendar Mukunda</name>
<email>Vijendar.Mukunda@amd.com</email>
</author>
<published>2026-06-09T16:08:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d23d53355300142779457af4f2ff58091ac9a2cb'/>
<id>urn:sha1:d23d53355300142779457af4f2ff58091ac9a2cb</id>
<content type='text'>
[ Upstream commit 6042c91df60e825625bc7d5c5c3b5a87b91d5805 ]

Firmware will set dsp_ack to 1 when firmware sends response for the IPC
command issued by host. Similarly dsp_msg flag will be updated to 1.

During ACP D0 entry, the value read from the sof_dsp_ack_write scratch
flag can be uninitialized. A non-zero garbage value is treated as a
pending DSP IPC ack before SOF_FW_BOOT_COMPLETE, causing a spurious
"IPC reply before FW_BOOT_COMPLETE" log.

Fix the condition checks for ipc flags.

Fixes: 738a2b5e2cc9 ("ASoC: SOF: amd: Add IPC support for ACP IP block")
Link: https://github.com/thesofproject/linux/pull/5642
Signed-off-by: Vijendar Mukunda &lt;Vijendar.Mukunda@amd.com&gt;
Tested-by: Umang Jain &lt;uajain@igalia.com&gt;
Link: https://patch.msgid.link/20260609160938.3717513-1-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ASoC: wm_adsp: Fix NULL dereference when removing firmware controls</title>
<updated>2026-06-19T11:43:58+00:00</updated>
<author>
<name>Richard Fitzgerald</name>
<email>rf@opensource.cirrus.com</email>
</author>
<published>2026-06-04T10:12:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=12e579b889624ec54a201d98fdff975de556c731'/>
<id>urn:sha1:12e579b889624ec54a201d98fdff975de556c731</id>
<content type='text'>
[ 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-&gt;priv
without checking the pointer for NULL.

Signed-off-by: Richard Fitzgerald &lt;rf@opensource.cirrus.com&gt;
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 &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ALSA: seq: dummy: fix UMP event stack overread</title>
<updated>2026-06-19T11:43:56+00:00</updated>
<author>
<name>Kyle Zeng</name>
<email>kylebot@openai.com</email>
</author>
<published>2026-06-05T08:02:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6671a46144f880c5a167930ebb14c12f3d059fe9'/>
<id>urn:sha1:6671a46144f880c5a167930ebb14c12f3d059fe9</id>
<content type='text'>
[ Upstream commit 2b5ff4db5d7aa5b981d966df02e687f79ad7b311 ]

The dummy sequencer port forwards events by copying an incoming
struct snd_seq_event into a stack temporary, rewriting source and
destination, and dispatching the temporary to subscribers. That legacy
event storage is smaller than struct snd_seq_ump_event.

When a UMP event reaches the dummy client, the copy leaves the UMP flag
set but only provides legacy-sized stack storage. The subscriber
delivery path then uses snd_seq_event_packet_size() and copies a
UMP-sized packet from that stack object, reading past the end of the
temporary.

Use the existing union __snd_seq_event storage and copy the packet size
reported for the incoming event before rewriting the common routing
fields. This preserves the full UMP packet for UMP events while keeping
legacy event handling unchanged.

Fixes: 32cb23a0f911 ("ALSA: seq: dummy: Allow UMP conversion")
Signed-off-by: Kyle Zeng &lt;kylebot@openai.com&gt;
Link: https://patch.msgid.link/20260605080204.32045-1-kylebot@openai.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams</title>
<updated>2026-06-19T11:43:56+00:00</updated>
<author>
<name>Ji'an Zhou</name>
<email>eilaimemedsnaimel@gmail.com</email>
</author>
<published>2026-06-04T14:25:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cd98837db15f323463b8df07282ac723bd5c3fed'/>
<id>urn:sha1:cd98837db15f323463b8df07282ac723bd5c3fed</id>
<content type='text'>
[ 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 &lt;eilaimemedsnaimel@gmail.com&gt;
Link: https://patch.msgid.link/20260604142559.3840881-1-eilaimemedsnaimel@gmail.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ALSA: hda/realtek: Fix speaker output on ASUS ROG Strix G615LP</title>
<updated>2026-06-09T10:28:42+00:00</updated>
<author>
<name>Zhang Heng</name>
<email>zhangheng@kylinos.cn</email>
</author>
<published>2026-05-26T01:36:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2ffd8b0dd4484b92325d3f7e098cdb66adff2ca2'/>
<id>urn:sha1:2ffd8b0dd4484b92325d3f7e098cdb66adff2ca2</id>
<content type='text'>
commit 20587302f8d700f26ee2c8a60ffb0a69ae0edf16 upstream.

Add quirk for ALC294 codec on ASUS ROG Strix G615LP
(SSID 1043:1214) using ALC287_FIXUP_TXNW2781_I2C_ASUS to
fix speaker output.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221173
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Zhang Heng &lt;zhangheng@kylinos.cn&gt;
Link: https://patch.msgid.link/20260526013611.1954949-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ASoC: qcom: q6asm-dai: do not set stream state in event and trigger callbacks</title>
<updated>2026-06-09T10:28:42+00:00</updated>
<author>
<name>Srinivas Kandagatla</name>
<email>srinivas.kandagatla@oss.qualcomm.com</email>
</author>
<published>2026-05-18T09:23:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c4609fff0665e8ec0e198aa43a0934dfe338e0c8'/>
<id>urn:sha1:c4609fff0665e8ec0e198aa43a0934dfe338e0c8</id>
<content type='text'>
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 &lt;srinivas.kandagatla@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260518092347.3446946-2-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ASoC: qcom: q6asm-dai: close stream only when running</title>
<updated>2026-06-09T10:28:42+00:00</updated>
<author>
<name>Srinivas Kandagatla</name>
<email>srinivas.kandagatla@oss.qualcomm.com</email>
</author>
<published>2026-05-18T09:23:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=35be14ea82982c2304b7d8a853957e0dd7537d77'/>
<id>urn:sha1:35be14ea82982c2304b7d8a853957e0dd7537d77</id>
<content type='text'>
commit 048c540ee76ded666bda74f9dae1ca3254e0633c upstream.

q6asm_dai_close() and q6asm_dai_compr_free() currently issue CMD_CLOSE
whenever prtd-&gt;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 &lt;srinivas.kandagatla@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260518092347.3446946-3-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
