CVE-2026-58098: Heap out-of-bounds access in semop(2)
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.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems running the Linux kernel where unprivileged local users can invoke semop(2) are exposed. The described impact is a kernel heap out-of-bounds access that could potentially allow local privilege escalation.
What does an attacker need to do to trigger the flaw?
An attacker needs to cause semop(2) to block on a semaphore condition, then create and destroy enough semaphore sets in the same table slot for the 15-bit sequence number to wrap before the blocked call wakes. This requires local unprivileged access.
How can administrators determine whether an exploitation attempt may be occurring?
The available information does not provide a specific log entry, kernel warning, or reliable indicator of attempted exploitation. Investigation would need to focus on suspicious local activity involving repeated creation and deletion of System V semaphore sets while semop(2) calls are blocked.