Race condition in ELF core dump segment counting
FreeBSD-SA-26:55.elf · CVE-2026-58088
Our decision for FreeSense
FreeBSD corrected this on 2026-07-29, before the FreeBSD source pin of every FreeSense version.
- Advisory: corrected 2026-07-29
- 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 | FixedFreeBSD pin of 2026-08-03 | 2026-08-03e004ff15 |
| FreeSense 1.11.1.9 | FixedFreeBSD pin of 2026-10-04 | 2026-10-04a52c50b4 |
| FreeSense 1.21.2.0-DEVELOPMENT | FixedFreeBSD pin of 2026-10-04 | 2026-10-04a52c50b4 |
Workaround
Set sysctl kern.coredump=0 to disable core dumps entirely.
What FreeBSD says
The ELF core dump code counted the number of dumpable VM map entries, allocated a buffer for the corresponding program headers, then iterated over the map a second time to populate them. A process sharing the address space via rfork(2) can mutate the map between the two passes, causing the second pass to write program headers past the end of the buffer.
Impact
An unprivileged local user sharing an address space with a process that dumps core can trigger an out-of-bounds write on the kernel heap, potentially leading to privilege escalation.
Excerpt from the FreeBSD advisory. Read the original for the full text and the fix.