Files
freebsd/sys/dev
Mark Johnston 658b24eba2 sound: Revalidate after reacquiring locks when resizing buffers
sndbuf_resize() and sndbuf_remalloc() drop the channel lock in order to
allocate the new buffer(s) with M_WAITOK.  Before doing that they verify
that the buffer is not mapped, but this could change while the lock is
dropped, as there is no higher-level synchronization which prevents
buffer resize (e.g., via the SNDCTL_DSP_SETBLKSIZE ioctl) from happening
concurrently with mmap.  Thus, these checks are insufficient.

Modify sndbuf_resize() and sndbuf_remalloc() to revalidate after
reacquiring the lock.  Extend them to check for a couple of channel
flags, mirroring the check in chn_resizebuf().  Modify chn_resizebuf()
to revalidate state after reacquiring the channel lock.

We could also allocate new buffers with M_NOWAIT and so avoid dropping
the lock.  Then, I think we could go even further and invoke
CHANNEL_SETBLOCKSIZE and CHANNEL_SETFRAGMENTS with the channel lock
held.  But really it would be better to ensure that dsp operations are
serialized; there is no reason for mmap and chn_resizebuf() to be able
to run in parallel, we should not be relying on the channel lock for
this.  So, let's keep a more minimal approach here.

Add a simple regression test.

Approved by:	so
Security:	FreeBSD-SA-26:71.sound
Security:	CVE-2026-101308
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D60554
2026-10-13 16:54:30 +00:00
..
2025-11-19 12:24:02 +01:00
2024-06-27 11:27:41 -04:00
2024-06-27 11:27:41 -04:00
2024-06-09 09:37:48 -04:00
2024-02-18 18:31:14 +00:00
2026-08-01 15:12:05 +00:00
2026-08-06 18:51:31 -05:00
…
2025-06-30 14:19:31 +00:00
…
2025-02-18 16:59:44 -07:00
2026-08-24 19:02:58 +00:00
…
2025-05-19 14:53:00 +02:00
…
…
…
…
…
…
2026-05-11 08:29:49 +00:00
…
2025-11-08 12:12:21 +01:00
2025-07-12 04:41:32 +03:00
2024-10-31 12:18:52 +01:00
…
…
2026-07-28 11:22:35 +02:00
…
2024-06-09 09:37:59 -04:00
…
…
…
…
2024-11-30 21:46:07 -05:00
…
2024-11-30 08:55:57 -05:00
…
2026-08-17 18:27:46 -07:00
2024-06-27 11:27:41 -04:00
2024-04-28 07:20:25 +02:00
…
…