Answer in brief
CVE-2026-58098 records a Unknown severity vulnerability in Heap out-of-bounds access in semop(2). The current sources do not mark it as known exploited. The current feed maps FreeBSD/FreeBSD (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps FreeBSD/FreeBSD (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| FreeBSD/FreeBSDgeneric | >=15.1-RELEASE <p4 || >=15.0-RELEASE <p14 || >=14.5-RELEASE <p1 || >=14.4-RELEASE <p10 | p4, p14, p1, p10 |
Published upstream
Oct 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 15, 2026
When semop(2) blocks waiting for a semaphore condition, it releases the per-set lock and sleeps. Upon waking, it checks the sequence number embedded in the semaphore set's IPC identifier to detect whether the set was removed while the caller was asleep. This sequence number is only 15 bits wide. If enough semaphore sets are created and destroyed in the same table slot while a caller is blocked, the counter wraps around, and semop(2) may falsely conclude that the original set still exists. The subsequent access to a semaphore within the set may then be out of bounds. An unprivileged local user can trigger an out-of-bounds access on kernel heap memory, potentially leading to privilege escalation.
Quoted source text, attributed separately from HOL analysis.