<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/sound/core, branch v6.6.131</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-25T10:05:48+00:00</updated>
<entry>
<title>ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain()</title>
<updated>2026-03-25T10:05:48+00:00</updated>
<author>
<name>Mehul Rao</name>
<email>mehulrao@gmail.com</email>
</author>
<published>2026-03-05T19:35:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=629cf09464cf98670996ea5c191dc9743e6f3f00'/>
<id>urn:sha1:629cf09464cf98670996ea5c191dc9743e6f3f00</id>
<content type='text'>
commit 9b1dbd69ba6f8f8c69bc7b77c2ce3b9c6ed05ba6 upstream.

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: 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-01-30T09:27:26+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=2de6d3348937f344ff2496f3cac172e3d123ff36'/>
<id>urn:sha1:2de6d3348937f344ff2496f3cac172e3d123ff36</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>
<entry>
<title>ALSA: pcm: Rewrite recalculate_boundary() to avoid costly loop</title>
<updated>2025-08-28T14:28:19+00:00</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@csgroup.eu</email>
</author>
<published>2025-06-06T09:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2f81d6e98f32ddbd4b0bec79abc65b99e319d02a'/>
<id>urn:sha1:2f81d6e98f32ddbd4b0bec79abc65b99e319d02a</id>
<content type='text'>
[ Upstream commit 92f59aeb13252265c20e7aef1379a8080c57e0a2 ]

At the time being recalculate_boundary() is implemented with a
loop which shows up as costly in a perf profile, as depicted by
the annotate below:

    0.00 :   c057e934:       3d 40 7f ff     lis     r10,32767
    0.03 :   c057e938:       61 4a ff ff     ori     r10,r10,65535
    0.21 :   c057e93c:       7d 49 50 50     subf    r10,r9,r10
    5.39 :   c057e940:       7d 3c 4b 78     mr      r28,r9
    2.11 :   c057e944:       55 29 08 3c     slwi    r9,r9,1
    3.04 :   c057e948:       7c 09 50 40     cmplw   r9,r10
    2.47 :   c057e94c:       40 81 ff f4     ble     c057e940 &lt;snd_pcm_ioctl+0xee0&gt;

Total: 13.2% on that simple loop.

But what the loop does is to multiply the boundary by 2 until it is
over the wanted border. This can be avoided by using fls() to get the
boundary value order and shift it by the appropriate number of bits at
once.

This change provides the following profile:

    0.04 :   c057f6e8:       3d 20 7f ff     lis     r9,32767
    0.02 :   c057f6ec:       61 29 ff ff     ori     r9,r9,65535
    0.34 :   c057f6f0:       7d 5a 48 50     subf    r10,r26,r9
    0.23 :   c057f6f4:       7c 1a 50 40     cmplw   r26,r10
    0.02 :   c057f6f8:       41 81 00 20     bgt     c057f718 &lt;snd_pcm_ioctl+0xf08&gt;
    0.26 :   c057f6fc:       7f 47 00 34     cntlzw  r7,r26
    0.09 :   c057f700:       7d 48 00 34     cntlzw  r8,r10
    0.22 :   c057f704:       7d 08 38 50     subf    r8,r8,r7
    0.04 :   c057f708:       7f 5a 40 30     slw     r26,r26,r8
    0.35 :   c057f70c:       7c 0a d0 40     cmplw   r10,r26
    0.13 :   c057f710:       40 80 05 f8     bge     c057fd08 &lt;snd_pcm_ioctl+0x14f8&gt;
    0.00 :   c057f714:       57 5a f8 7e     srwi    r26,r26,1

Total: 1.7% with that loopless alternative.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Link: https://patch.msgid.link/4836e2cde653eebaf2709ebe30eec736bb8c67fd.1749202237.git.christophe.leroy@csgroup.eu
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 race of buffer access at PCM OSS layer</title>
<updated>2025-06-04T12:42:19+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2025-05-16T08:08:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=74d90875f3d43f3eff0e9861c4701418795d3455'/>
<id>urn:sha1:74d90875f3d43f3eff0e9861c4701418795d3455</id>
<content type='text'>
commit 93a81ca0657758b607c3f4ba889ae806be9beb73 upstream.

The PCM OSS layer tries to clear the buffer with the silence data at
initialization (or reconfiguration) of a stream with the explicit call
of snd_pcm_format_set_silence() with runtime-&gt;dma_area.  But this may
lead to a UAF because the accessed runtime-&gt;dma_area might be freed
concurrently, as it's performed outside the PCM ops.

For avoiding it, move the code into the PCM core and perform it inside
the buffer access lock, so that it won't be changed during the
operation.

Reported-by: syzbot+32d4647f551007595173@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/68164d8e.050a0220.11da1b.0019.GAE@google.com
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://patch.msgid.link/20250516080817.20068-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>ALSA: seq: Improve data consistency at polling</title>
<updated>2025-06-04T12:42:01+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2025-03-07T08:42:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8c1a16d612ef7f824b87f1a54f5de1f5a6e870ab'/>
<id>urn:sha1:8c1a16d612ef7f824b87f1a54f5de1f5a6e870ab</id>
<content type='text'>
[ Upstream commit e3cd33ab17c33bd8f1a9df66ec83a15dd8f7afbb ]

snd_seq_poll() calls snd_seq_write_pool_allocated() that reads out a
field in client-&gt;pool object, while it can be updated concurrently via
ioctls, as reported by syzbot.  The data race itself is harmless, as
it's merely a poll() call, and the state is volatile.  OTOH, the read
out of poll object info from the caller side is fragile, and we can
leave it better in snd_seq_pool_poll_wait() alone.

A similar pattern is seen in snd_seq_kernel_client_write_poll(), too,
which is called from the OSS sequencer.

This patch drops the pool checks from the caller side and add the
pool-&gt;lock in snd_seq_pool_poll_wait() for better data consistency.

Reported-by: syzbot+2d373c9936c00d7e120c@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/67c88903.050a0220.15b4b9.0028.GAE@google.com
Link: https://patch.msgid.link/20250307084246.29271-1-tiwai@suse.de
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: seq: Fix delivery of UMP events to group ports</title>
<updated>2025-05-22T12:12:16+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2025-05-11T13:45:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8a8dc7fd1e3b0cf0b1b387cbf3c5fe6ffde42907'/>
<id>urn:sha1:8a8dc7fd1e3b0cf0b1b387cbf3c5fe6ffde42907</id>
<content type='text'>
[ Upstream commit ff7b190aef6cccdb6f14d20c5753081fe6420e0b ]

When an event with UMP message is sent to a UMP client, the EP port
receives always no matter where the event is sent to, as it's a
catch-all port.  OTOH, if an event is sent to EP port, and if the
event has a certain UMP Group, it should have been delivered to the
associated UMP Group port, too, but this was ignored, so far.

This patch addresses the behavior.  Now a UMP event sent to the
Endpoint port will be delivered to the subscribers of the UMP group
port the event is associated with.

The patch also does a bit of refactoring to simplify the code about
__deliver_to_subscribers().

Fixes: 177ccf811df4 ("ALSA: seq: Support MIDI 2.0 UMP Endpoint port")
Link: https://patch.msgid.link/20250511134528.6314-1-tiwai@suse.de
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: seq: Avoid module auto-load handling at event delivery</title>
<updated>2025-03-13T11:58:24+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2025-03-01T11:45:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5e1b3bf72710c29488b59f8489344f10e9b24170'/>
<id>urn:sha1:5e1b3bf72710c29488b59f8489344f10e9b24170</id>
<content type='text'>
commit c9ce148ea753bef66686460fa3cec6641cdfbb9f upstream.

snd_seq_client_use_ptr() is supposed to return the snd_seq_client
object for the given client ID, and it tries to handle the module
auto-loading when no matching object is found.  Although the module
handling is performed only conditionally with "!in_interrupt()", this
condition may be fragile, e.g. when the code is called from the ALSA
timer callback where the spinlock is temporarily disabled while the
irq is disabled.  Then his doesn't fit well and spews the error about
sleep from invalid context, as complained recently by syzbot.

Also, in general, handling the module-loading at each time if no
matching object is found is really an overkill.  It can be still
useful when performed at the top-level ioctl or proc reads, but it
shouldn't be done at event delivery at all.

For addressing the issues above, this patch disables the module
handling in snd_seq_client_use_ptr() in normal cases like event
deliveries, but allow only in limited and safe situations.
A new function client_load_and_use_ptr() is used for the cases where
the module loading can be done safely, instead.

Reported-by: syzbot+4cb9fad083898f54c517@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/67c272e5.050a0220.dc10f.0159.GAE@google.com
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://patch.msgid.link/20250301114530.8975-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>ALSA: seq: Drop UMP events when no UMP-conversion is set</title>
<updated>2025-02-27T12:10:48+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2025-02-17T17:00:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=48e348ff3e180509f457e1251fb3471d430a25eb'/>
<id>urn:sha1:48e348ff3e180509f457e1251fb3471d430a25eb</id>
<content type='text'>
[ Upstream commit e77aa4b2eaa7fb31b2a7a50214ecb946b2a8b0f6 ]

When a destination client is a user client in the legacy MIDI mode and
it sets the no-UMP-conversion flag, currently the all UMP events are
still passed as-is.  But this may confuse the user-space, because the
event packet size is different from the legacy mode.

Since we cannot handle UMP events in user clients unless it's running
in the UMP client mode, we should filter out those events instead of
accepting blindly.  This patch addresses it by slightly adjusting the
conditions for UMP event handling at the event delivery time.

Fixes: 329ffe11a014 ("ALSA: seq: Allow suppressing UMP conversions")
Link: https://lore.kernel.org/b77a2cd6-7b59-4eb0-a8db-22d507d3af5f@gmail.com
Link: https://patch.msgid.link/20250217170034.21930-1-tiwai@suse.de
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: seq: Make dependency on UMP clearer</title>
<updated>2025-02-08T08:52:07+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2025-01-01T12:55:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=19f17a762ebda04e1bf9265f30b1b63fe8103683'/>
<id>urn:sha1:19f17a762ebda04e1bf9265f30b1b63fe8103683</id>
<content type='text'>
[ Upstream commit 9001d515443518d72222ba4d58e247696b625071 ]

CONFIG_SND_SEQ_UMP_CLIENT is a Kconfig for a sequencer client
corresponding to the UMP rawmidi, while we have another major knob
CONFIG_SND_SEQ_UMP that specifies whether the sequencer core supports
UMP packets or not.  Strictly speaking both of them are independent,
but practically seen, it makes no sense to enable
CONFIG_SND_SEQ_UMP_CLIENT without UMP support itself.

This patch makes such an implicit dependency clearer.  Now
CONFIG_SND_SEQ_UMP_CLIENT depends on both CONFIG_SND_UMP and
CONFIG_SND_SEQ_UMP.  Meanwhile, CONFIG_SND_SEQ_UMP is enabled as
default when CONFIG_SND_UMP is set.

Fixes: 81fd444aa371 ("ALSA: seq: Bind UMP device")
Link: https://patch.msgid.link/20250101125548.25961-1-tiwai@suse.de
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: seq: remove redundant 'tristate' for SND_SEQ_UMP_CLIENT</title>
<updated>2025-02-08T08:52:06+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2024-02-15T13:53:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7bd0bb51bd92930769a349d35bcc459c29aeaddf'/>
<id>urn:sha1:7bd0bb51bd92930769a349d35bcc459c29aeaddf</id>
<content type='text'>
[ Upstream commit 8e8bc5000328a1ba8f93d43faf427e8ac31fb416 ]

'def_tristate' is a shorthand for 'default' + 'tristate'.

Another 'tristate' is redundant.

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Link: https://lore.kernel.org/r/20240215135304.1909431-1-masahiroy@kernel.org
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Stable-dep-of: 9001d5154435 ("ALSA: seq: Make dependency on UMP clearer")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
