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.
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.
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.
Metrics
Affected Vendors & Products
Advisories
No advisories yet.
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Thu, 15 Oct 2026 13:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. 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. | |
| Title | TOCTOU race between sound(4) buffer resizing and mmap | |
| Weaknesses | CWE-367 | |
| References |
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: freebsd
Published:
Updated: 2026-10-15T15:40:12.607Z
Reserved: 2026-09-28T13:33:02.323Z
Link: CVE-2026-101308
No data.
Status : Received
Published: 2026-10-15T07:17:58.007
Modified: 2026-10-15T07:17:58.007
Link: CVE-2026-101308
No data.
OpenCVE Enrichment
No data.
Weaknesses