FreeSenseFreeSenseSecurity
freesense.org
← Fixed vulnerabilities
Fixed

Heap out-of-bounds access in semctl(2)

FreeBSD-SA-26:54.sysvsem · CVE-2026-58087

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)
Decided by rules, not yet reviewed. The status comes from the advisory's correction date and the build configuration. A maintainer has not looked at whether FreeSense is exposed in practice. How we triage

By FreeSense version

VersionStatusFreeBSD pin
FreeSense 1.01.0.7 · frozen, no further fixesFixedFreeBSD pin of 2026-08-032026-08-03e004ff15
FreeSense 1.11.1.9FixedFreeBSD pin of 2026-10-042026-10-04a52c50b4
FreeSense 1.21.2.0-DEVELOPMENTFixedFreeBSD pin of 2026-10-042026-10-04a52c50b4

Workaround

No workaround is available.

What FreeBSD says

The GETALL and SETALL commands in semctl(2) recorded the number of semaphores in the target set, dropped the lock protecting the set, allocated a buffer sized for that count, and reacquired the lock. A sequence-number check was used to verify that the set had not been replaced in the interim, but the sequence number wraps after 0x8000 create/destroy cycles. By rapidly destroying and recreating semaphore sets at the same index, another process can cause the sequence number to wrap, allowing a set with a different number of semaphores to pass validation. The subsequent copy then reads or writes past the end of the allocated buffer.

Impact

An unprivileged local user can trigger out-of-bounds reads and writes on kernel heap memory, potentially leading to privilege escalation.

Excerpt from the FreeBSD advisory. Read the original for the full text and the fix.

Copied to clipboard