<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/sound/core, branch v5.10.259</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.259</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.259'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-19T11:21:41+00:00</updated>
<entry>
<title>ALSA: core: Fix potential data race at fasync handling</title>
<updated>2026-06-19T11:21:41+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2026-05-03T11:03:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=966a382dfdb859d372fa298fa72b28cb3510c238'/>
<id>urn:sha1:966a382dfdb859d372fa298fa72b28cb3510c238</id>
<content type='text'>
[ 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-&gt;on, fasync-&gt;signal and fasync-&gt;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-&gt;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-&gt;on flag.

Reported-by: Jake Lamberson &lt;lamberson.jake@gmail.com&gt;
Fixes: ef34a0ae7a26 ("ALSA: core: Add async signal helpers")
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://patch.msgid.link/20260420061721.3253644-1-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
[ replaced scoped_guard(spinlock_irq, &amp;snd_fasync_lock) with explicit spin_lock_irq()/spin_unlock_irq() ]
Signed-off-by: Sasha Levin &lt;sashal@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:21:37+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=92ad2d7f80cad43b046f093e808e11fe919d304a'/>
<id>urn:sha1:92ad2d7f80cad43b046f093e808e11fe919d304a</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: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams</title>
<updated>2026-06-19T11:21:35+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=cac5bf3500ee6422cf64e0df0b5daeecfed42917'/>
<id>urn:sha1:cac5bf3500ee6422cf64e0df0b5daeecfed42917</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: core: Validate compress device numbers without dynamic minors</title>
<updated>2026-06-01T15:29:33+00:00</updated>
<author>
<name>Cássio Gabriel</name>
<email>cassiogabrielcontato@gmail.com</email>
</author>
<published>2026-03-25T05:24:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fe249b8127abffc90f78071ea2d72c79c45a1a9a'/>
<id>urn:sha1:fe249b8127abffc90f78071ea2d72c79c45a1a9a</id>
<content type='text'>
[ Upstream commit 796e119e9b14763be905ad0d023c71a14bc2e931 ]

Without CONFIG_SND_DYNAMIC_MINORS, ALSA reserves only two fixed minors
for compress devices on each card: comprD0 and comprD1.

snd_find_free_minor() currently computes the compress minor as
type + dev without validating dev first, so device numbers greater than
1 spill into the HWDEP minor range instead of failing registration.

ASoC passes rtd-&gt;id to snd_compress_new(), so this can happen on real
non-dynamic-minor builds.

Add a dedicated fixed-minor check for SNDRV_DEVICE_TYPE_COMPRESS in
snd_find_free_minor() and reject out-of-range device numbers with
-EINVAL before constructing the minor.

Also remove the stale TODO in compress_offload.c that still claims
multiple compress nodes are missing.

Fixes: 3eafc959b32f ("ALSA: core: add support for compressed devices")
Signed-off-by: Cássio Gabriel &lt;cassiogabrielcontato@gmail.com&gt;
Link: https://patch.msgid.link/20260325-alsa-compress-static-minors-v1-1-0628573bee1c@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: compress: Drop unused functions</title>
<updated>2026-06-01T15:29:33+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2021-07-14T16:24:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8cb04a830e96345cbaa3880e24eb9a91ac62461f'/>
<id>urn:sha1:8cb04a830e96345cbaa3880e24eb9a91ac62461f</id>
<content type='text'>
[ Upstream commit fc93c96fe34e10b873fef73e80cee52503f3a679 ]

snd_compress_register() and snd_compress_deregister() API functions
have been never used by in-tree drivers.
Let's clean up the dead code.

Acked-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Reviewed-by: Peter Ujfalusi &lt;peter.ujfalusi@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20210714162424.4412-2-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Stable-dep-of: 796e119e9b14 ("ALSA: core: Validate compress device numbers without dynamic minors")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ALSA: seq_oss: return full count for successful SEQ_FULLSIZE writes</title>
<updated>2026-06-01T15:29:19+00:00</updated>
<author>
<name>Cássio Gabriel</name>
<email>cassiogabrielcontato@gmail.com</email>
</author>
<published>2026-03-24T19:59:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6d1b529e9979db6825faa6c19e962008f6f87229'/>
<id>urn:sha1:6d1b529e9979db6825faa6c19e962008f6f87229</id>
<content type='text'>
commit bbc6c0dda54fc0ad8f8aed0b796c23e186e1a188 upstream.

snd_seq_oss_write() currently returns the raw load_patch() callback
result for SEQ_FULLSIZE events.

That callback is documented as returning 0 on success and -errno on
failure, but snd_seq_oss_write() is the file write path and should
report the number of user bytes consumed on success. Some in-tree
backends also return backend-specific positive values, which can still
be shorter than the original write size.

Return the full byte count for successful SEQ_FULLSIZE writes.
Preserve negative errors and convert any nonnegative completion to the
original count.

Cc: stable@vger.kernel.org
Signed-off-by: Cássio Gabriel &lt;cassiogabrielcontato@gmail.com&gt;
Link: https://patch.msgid.link/20260324-alsa-seq-oss-fullsize-write-return-v1-1-66d448510538@gmail.com
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: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names()</title>
<updated>2026-06-01T15:29:18+00:00</updated>
<author>
<name>Ziqing Chen</name>
<email>chenziqing@xiaomi.com</email>
</author>
<published>2026-04-14T13:24:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=708f6ec9bcdf58bfd561409110baaf4fd3be4ea3'/>
<id>urn:sha1:708f6ec9bcdf58bfd561409110baaf4fd3be4ea3</id>
<content type='text'>
commit e0da8a8cac74f4b9f577979d131f0d2b88a84487 upstream.

snd_ctl_elem_init_enum_names() advances pointer p through the names
buffer while decrementing buf_len. If buf_len reaches zero but items
remain, the next iteration calls strnlen(p, 0).

While strnlen(p, 0) returns 0 and would hit the existing name_len == 0
error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks
maxlen against __builtin_dynamic_object_size(). When Clang loses track
of p's object size inside the loop, this triggers a BRK exception panic
before the return value is examined.

Add a buf_len == 0 guard at the loop entry to prevent calling fortified
strnlen() on an exhausted buffer.

Found by kernel fuzz testing through Xiaomi Smartphone.

Fixes: 8d448162bda5 ("ALSA: control: add support for ENUMERATED user space controls")
Cc: stable@vger.kernel.org
Signed-off-by: Ziqing Chen &lt;chenziqing@xiaomi.com&gt;
Link: https://patch.msgid.link/20260414132437.261304-1-chenziqing@xiaomi.com
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: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain()</title>
<updated>2026-04-18T08:31:01+00:00</updated>
<author>
<name>Mehul Rao</name>
<email>mehulrao@gmail.com</email>
</author>
<published>2026-03-16T17:00:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9baee36e8c5443411c4629afabafaff8a46a23fd'/>
<id>urn:sha1:9baee36e8c5443411c4629afabafaff8a46a23fd</id>
<content type='text'>
[ Upstream commit 9b1dbd69ba6f8f8c69bc7b77c2ce3b9c6ed05ba6 ]

In the drain loop, the local variable 'runtime' is reassigned to a
linked stream's runtime (runtime = s-&gt;runtime at line 2157).  After
releasing the stream lock at line 2169, the code accesses
runtime-&gt;no_period_wakeup, runtime-&gt;rate, and runtime-&gt;buffer_size
(lines 2170-2178) — all referencing the linked stream's runtime without
any lock or refcount protecting its lifetime.

A concurrent close() on the linked stream's fd triggers
snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private()
→ snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime).
No synchronization prevents kfree(runtime) from completing while the
drain path dereferences the stale pointer.

Fix by caching the needed runtime fields (no_period_wakeup, rate,
buffer_size) into local variables while still holding the stream lock,
and using the cached values after the lock is released.

Fixes: f2b3614cefb6 ("ALSA: PCM - Don't check DMA time-out too shortly")
Cc: stable@vger.kernel.org
Signed-off-by: Mehul Rao &lt;mehulrao@gmail.com&gt;
Link: https://patch.msgid.link/20260305193508.311096-1-mehulrao@gmail.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: pcm: fix wait_time calculations</title>
<updated>2026-04-18T08:31:01+00:00</updated>
<author>
<name>Oswald Buddenhagen</name>
<email>oswald.buddenhagen@gmx.de</email>
</author>
<published>2026-03-16T17:00:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d1a753dca0b24b930f7bd8f1ee4c9bed9252f863'/>
<id>urn:sha1:d1a753dca0b24b930f7bd8f1ee4c9bed9252f863</id>
<content type='text'>
[ Upstream commit 3ed2b549b39f57239aad50a255ece353997183fd ]

... in wait_for_avail() and snd_pcm_drain().

t was calculated in seconds, so it would be pretty much always zero, to
be subsequently de-facto ignored due to being max(t, 10)'d. And then it
(i.e., 10) would be treated as secs, which doesn't seem right.

However, fixing it to properly calculate msecs would potentially cause
timeouts when using twice the period size for the default timeout (which
seems reasonable to me), so instead use the buffer size plus 10 percent
to be on the safe side ... but that still seems insufficient, presumably
because the hardware typically needs a moment to fire up. To compensate
for this, we up the minimal timeout to 100ms, which is still two orders
of magnitude less than the bogus minimum.

substream-&gt;wait_time was also misinterpreted as jiffies, despite being
documented as being in msecs. Only the soc/sof driver sets it - to 500,
which looks very much like msecs were intended.

Speaking of which, shouldn't snd_pcm_drain() also use substream-&gt;
wait_time?

As a drive-by, make the debug messages on timeout less confusing.

Signed-off-by: Oswald Buddenhagen &lt;oswald.buddenhagen@gmx.de&gt;
Link: https://lore.kernel.org/r/20230405201219.2197774-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Stable-dep-of: 9b1dbd69ba6f ("ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain()")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: pcm: Improve the fix for race of buffer access at PCM OSS layer</title>
<updated>2026-02-06T15:40:00+00:00</updated>
<author>
<name>Jaroslav Kysela</name>
<email>perex@perex.cz</email>
</author>
<published>2026-01-07T21:36:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a1748063cac4c5b3bd9107078df56c585d7527ab'/>
<id>urn:sha1:a1748063cac4c5b3bd9107078df56c585d7527ab</id>
<content type='text'>
commit 47c27c9c9c720bc93fdc69605d0ecd9382e99047 upstream.

Handle the error code from snd_pcm_buffer_access_lock() in
snd_pcm_runtime_buffer_set_silence() function.

Found by Alexandros Panagiotou &lt;apanagio@redhat.com&gt;

Fixes: 93a81ca06577 ("ALSA: pcm: Fix race of buffer access at PCM OSS layer")
Cc: stable@vger.kernel.org # 6.15
Signed-off-by: Jaroslav Kysela &lt;perex@perex.cz&gt;
Link: https://patch.msgid.link/20260107213642.332954-1-perex@perex.cz
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
