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.
Fix
Patch, vendor advisory and mitigation references on NVD 1
- https://security.freebsd.org/advisories/FreeBSD-SA-26:71.sound.asc Patch, Vendor Advisory
Every line above is quoted from NVD, CISA, Microsoft, the vendor's own advisory or DISA; nothing is generated.
Change history 5
- Cpes+18 CPE criteria (now 18)NVD modified 2026-10-19 21:07
- StatusAwaiting Analysis → AnalyzedNVD modified 2026-10-19 21:07
- StatusReceived → Awaiting AnalysisNVD modified 2026-10-15 16:17
- CVSS5.5 (v3.1, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)NVD modified 2026-10-15 16:17
- First seenunscoredNVD modified 2026-10-15 07:17
Affected (CPE criteria) 18
cpe:2.3:o:freebsd:freebsd:14.4:-:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.4:p1:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.4:p10:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.4:p2:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.4:p3:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.4:p4:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.4:p5:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.4:p6:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.4:p7:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.4:p8:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.4:p9:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.5:-:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:14.5:p1:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:15.1:-:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:15.1:p1:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:15.1:p2:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:15.1:p3:*:*:*:*:*:*cpe:2.3:o:freebsd:freebsd:15.1:p4:*:*:*:*:*:*
References 1
- https://security.freebsd.org/advisories/FreeBSD-SA-26:71.sound.asc Patch, Vendor Advisory