CVE-2026-58087 in FreeBSD
Summary
by MITRE • 08/19/2026
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.
An unprivileged local user can trigger out-of-bounds reads and writes on kernel heap memory, potentially leading to privilege escalation.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability resides within the System V semaphore implementation in the Linux kernel, specifically affecting the semctl system call when invoked with GETALL or SETALL commands. The core technical flaw stems from a race condition involving sequence number validation and buffer allocation logic. When handling these requests, the kernel first records the current count of semaphores in the target set to determine the required buffer size for copying data between user space and kernel space. Crucially, this operation occurs while dropping the lock protecting the semaphore set, allocating the necessary memory based on that recorded count, and then reacquiring the lock before proceeding with the actual copy operations. To prevent issues arising from concurrent modifications during this window, the implementation relies on a sequence number check to verify that the semaphore set has not been replaced or significantly altered since the initial read of its properties.
The critical failure lies in the handling of this sequence number, which is implemented as an unsigned short integer with a maximum value threshold before wrapping occurs at 0x8000 create or destroy cycles. An attacker can exploit this by rapidly destroying and recreating semaphore sets at the same index within the kernel's internal data structures. This high-frequency churn causes the sequence counter to wrap around, effectively resetting its value. Because the validation logic only checks if the current sequence number matches the one recorded earlier in the operation, a wrapped sequence number that coincidentally matches the original pre-modification state will pass this check. Consequently, the kernel proceeds with buffer allocation and data copying based on stale or mismatched metadata regarding the actual size of the semaphore set currently occupying that index.
This logic error leads directly to out-of-bounds memory access within the kernel heap. Since the allocated buffer was sized according to the initial count read before the lock drop, but the actual semaphore set may now contain a different number of semaphores due to the rapid recreation by an attacker, the subsequent copy operation will either read from or write past the end of the allocated buffer. This results in arbitrary kernel heap memory corruption. The impact is severe because it allows for information disclosure through out-of-bounds reads and code execution potential via out-of-bounds writes. An unprivileged local user can leverage this flaw to manipulate kernel data structures, potentially leading to full privilege escalation from a standard user context to root-level access on the affected system.
From a classification perspective, this vulnerability aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization of Sequence Points, as it involves a race condition where shared resources are accessed without proper synchronization ensuring atomicity of state checks and actions. It also relates to CWE-190: Integer Overflow or Wraparound due to the sequence number wrapping behavior that facilitates the bypass of validation logic. In terms of offensive security frameworks such as MITRE ATT&CK, this technique falls under T1068: Exploitation for Privilege Escalation and specifically utilizes techniques associated with local privilege escalation through kernel vulnerabilities. The attack vector is classified as Local (L) because it requires an account on the system to trigger the semaphore operations.
Mitigation strategies primarily involve applying vendor-provided security patches that address this race condition in the Linux kernel source code. These updates typically correct the synchronization logic by ensuring that sequence number validation and buffer allocation occur under a consistent lock hold, or they implement more robust checks that do not rely solely on wrapping counters for integrity verification during critical sections of semaphore operations. System administrators should ensure their systems are updated to versions where this specific race condition in semctl handling has been resolved. Additionally, deploying intrusion detection signatures capable of identifying abnormal patterns of rapid semaphore creation and destruction could provide an early warning indicator of exploitation attempts against unpatched systems.