TOCTOU race between sound(4) buffer resizing and mmap
FreeBSD-SA-26:71.sound · CVE-2026-101308
Our decision for FreeSense
FreeBSD corrected this on 2026-10-14, after the FreeBSD source pin of FreeSense 1.0 (pinned 2026-08-03), FreeSense 1.1 (pinned 2026-10-04), FreeSense 1.2 (pinned 2026-10-04). The fix arrives with the next FreeBSD pin of each line that is still updated. No one has checked yet whether FreeSense is exposed in practice.
- Advisory: corrected 2026-10-14
- FreeSense 1.0 pin: e004ff15f87e (2026-08-03)
- FreeSense 1.1 pin: a52c50b4b7c2 (2026-10-04)
- FreeSense 1.2 pin: a52c50b4b7c2 (2026-10-04)
By FreeSense version
| Version | Status | FreeBSD pin |
|---|---|---|
| FreeSense 1.01.0.7 · frozen, no further fixes | Open | 2026-08-03e004ff15 |
| FreeSense 1.11.1.9 | Open | 2026-10-04a52c50b4 |
| FreeSense 1.21.2.0-DEVELOPMENT | Open | 2026-10-04a52c50b4 |
Workaround
No workaround is available. Systems with no sound devices are unaffected.
What FreeBSD says
When an audio channel's buffer needs to be resized, the sound(4) driver checks that the buffer is not memory-mapped and then drops the channel lock to allocate a new buffer. An mmap(2) call on another thread can complete during this window, after which the resize path frees the now-mapped buffer without rechecking.
Impact
An unprivileged local user with access to a sound device can exploit this race to trigger a use-after-free in the kernel, potentially escalating privileges.
Excerpt from the FreeBSD advisory. Read the original for the full text and the fix.