Decades-Old Integer Overflow Chained With Kernel Flaw Yields Root Access on OpenBSD 7.9

A newly published local privilege escalation exploit successfully achieves root access on OpenBSD 7.9 by ingeniously chaining a roughly 37-year-old integer overflow with a separate kernel vulnerability. This sophisticated attack vector manages to effectively bypass OpenBSD’s built-in Kernel Address Randomization Link (KARL) security mechanism, as well as crucial hardware-enforced Supervisor Mode Access Prevention (SMAP) and Supervisor Mode Execution Prevention (SMEP) protections.

The security firm Calif, which originally discovered and reported these critical flaws, has published a comprehensive technical write-up alongside fully functional proof-of-concept exploit code. These releases follow OpenBSD’s prompt deployment of official patches addressing both underlying issues back in September.

The initial component of the exploit chain targets an integer overflow residing within the shmat(4) shared memory attach function. This specific vulnerability was addressed and resolved in errata 018, which was shipped on September 14 as part of routine reliability updates. The second component, a reference-counting use-after-free vulnerability that completes the full exploit chain, was patched separately via errata 026 and distributed on September 30 as a dedicated security fix.

Both patches are readily available to system administrators through OpenBSD’s native syspatch utility and encompass support across all supported system architectures. Notably, OpenBSD 7.8 also received the specific integer-overflow fix. Because the integer overflow—which serves as the primary entry point for the entire exploit chain—was categorized and treated as a reliability fix rather than an explicit security fix, it highlights the often unpredictable security implications of legacy code paths. As of the time of publication, no official CVE (Common Vulnerabilities and Exposures) identifiers have been assigned to either of the two flaws, and security monitors have found no active evidence indicating that these vulnerabilities have been exploited in the wild.

The root cause of the initial vulnerability traces back to the shared-memory attachment counter, known as shm_nattch. In the original BSD source code dating all the way back to 1988, this counter was defined as a signed 16-bit short integer with a hard ceiling maximum value of 32,767. Over the ensuing decades, OpenBSD inherited this legacy type definition and never widened the variable to accommodate modern memory scales.

To weaponize this historic design choice, the newly published exploit maps an aggregate of 127 distinct shared-memory segments and concurrently forks 259 processes. This aggressive action successfully forces the counter past its maximum allowable numerical threshold, causing it to integer-wrap around into a negative value of minus 32,643. Immediately following this state corruption, a race condition is introduced that triggers a severe use-after-free scenario. The corrupted and inaccurate reference count misleads the kernel into prematurely freeing memory blocks that other active processes are still actively referencing and utilizing.

With memory integrity compromised, a separate out-of-bounds write operation is executed to overwrite critical multicast-membership counters within the kernel’s internal structures. When the affected network socket is eventually closed, the resulting numerical decrements inadvertently modify underlying page-table entries. This manipulation successfully switches a standard user-memory mapping so that it becomes supervisor-accessible, effectively neutralizing the hardware-level defenses provided by SMAP and SMEP. Once these protections are bypassed, the exploit proceeds to overwrite a function pointer residing at a predictable kernel memory address, allowing the malicious payload to execute arbitrary code with elevated privileges.

Detailing the mechanics behind the KARL bypass, researcher Andrew Griffiths explained that while OpenBSD’s KARL utility actively relinks the kernel binary upon boot to randomize the memory locations of both functions and data addresses, the underlying kernel memory allocators themselves remain deterministic. Because both the boot-time allocators and the best-fit allocators lack proper base-address randomization, early-boot structural elements—such as vital function pointers located within the lo0 and enc0 network-interface handlers—consistently land at identical memory addresses across subsequent reboots on the exact same hardware configuration. Consequently, the exploit achieves its objectives entirely without needing to rely on a separate information-disclosure vulnerability to leak memory layouts.

In light of these findings, security firm Calif has put forward four distinct categories of system hardening designed to prevent similar exploit chains in the future. These recommendations include implementing safe-unlinking protocols for kernel linked lists—a protective measure already adopted by competing operating systems like FreeBSD and NetBSD—alongside the randomization of page-table self-referential mappings, the introduction of kernel-allocator randomization, and advanced compiler-based bounds checking.

Calif confirmed that it initially reported the discovered flaws to the OpenBSD development team earlier this year, allowing sufficient time for remediation prior to public disclosure. The complete proof-of-concept exploit code has been made publicly accessible to the security research community via GitHub.