Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-19T08:17:12.877Z",
  "pubdate": "2026-08-19T08:17:12.877Z",
  "executiveSummary": "A critical vulnerability exists within the Linux kernel IPC subsystem, specifically in the semctl(2) system call handling of GETALL and SETALL commands. The vulnerability allows an unprivileged local user to trigger out-of-bounds reads and writes on kernel heap memory, creating a severe risk of local privilege escalation and system compromise.\nThe flaw stems from an insecure validation mechanism when managing semaphore set state across unlocked critical sections. An attacker can exploit this race condition by rapidly cycling the creation and destruction of semaphore sets to induce a sequence-number wrap, bypassing integrity checks.\nSuccessful exploitation requires local access with the ability to execute unprivileged code on the target system. Because the vulnerability directly corrupts kernel heap memory structures, an attacker can potentially manipulate kernel execution flow, elevate privileges to root, or cause a denial of service via kernel panics.",
  "technicalDetails": "The vulnerability resides in the semctl(2) system call implementation within the Linux kernel IPC subsystem, specifically affecting the handling of the GETALL and SETALL commands. The core vulnerable component is the synchronization and validation logic used when operating on semaphore sets.\nThe root cause is a race condition combined with insufficient state validation across dropped locks. During the execution of GETALL or SETALL, the kernel records the number of semaphores present in the target set, temporarily drops the internal lock protecting the set, allocates a kernel heap buffer sized proportionally to the initially recorded semaphore count, and subsequently reacquires the lock.\nTo verify that the target semaphore set has not been altered or replaced during the unlocked window, the kernel relies on a sequence-number check. However, this sequence number wraps around after 0x8000 create and destroy cycles. An unprivileged local attacker can induce this wrap condition by rapidly and repeatedly destroying and recreating semaphore sets at the exact same IPC index.\nBy forcing the sequence number to wrap back to the expected value, the attacker tricks the validation logic into accepting a newly swapped-in semaphore set that possesses a different number of semaphores than the buffer was originally allocated for. Consequently, when the kernel performs the subsequent copy operation to or from user space, it reads or writes past the bounds of the dynamically allocated kernel heap buffer, resulting in a heap-based buffer overflow.\nThe attack flow proceeds as follows: 1) The attacker initiates a GETALL or SETALL operation on a target semaphore set. 2) The kernel records the semaphore count, drops the set lock, and allocates the heap buffer. 3) The attacker rapidly floods the system with a sequence of IPC create and destroy operations targeting the same index, causing the sequence-number counter to wrap. 4) The attacker substitutes the original semaphore set with a malformed set containing a disparate semaphore count. 5) The kernel reacquires the lock, trusts the wrapped sequence number, and performs out-of-bounds memory accesses during the data copy phase. 6) The resulting kernel heap corruption is leveraged by the attacker to overwrite adjacent sensitive kernel objects, achieving arbitrary code execution and local privilege escalation."
}