OpenBSD root exploit chain fixed in September patches
The OpenBSD root exploit demonstrated by security firm Calif can give a local user root, the operating system's highest level of administrative control, on OpenBSD 7.9. The proof of concept chains an integer overflow in shared memory with another flaw in the kernel, the core of the operating system. Together, the weaknesses bypass OpenBSD's kernel-address randomization and the SMAP and SMEP processor protections intended to stop the kernel from improperly accessing or executing user-controlled memory.
OpenBSD addressed the two underlying issues in separate September updates. Errata 018, released on September 14, corrected the integer overflow in the shmat(4) function used to attach shared memory, which lets processes access the same area of memory. OpenBSD classified that update as a reliability fix rather than a security fix. Errata 026 followed on September 30 and fixed the reference-counting use-after-free, a condition in which the kernel continues using memory after it has been released. That update was classified as a security fix.
Both corrections are available through syspatch, OpenBSD's patch utility, and apply across all supported hardware architectures. OpenBSD 7.8 also received the integer-overflow correction. No CVE identifier had been assigned to either vulnerability at publication, and there was no evidence that attackers had exploited them. Calif said it reported the flaws to OpenBSD earlier this year, then released a detailed technical analysis and complete proof-of-concept code on GitHub after the patches became available.
The first stage targets shm_nattch, the counter that records how many processes have attached a shared-memory segment. It is stored as a signed 16-bit short integer with a maximum value of 32,767. Calif traced that design to original BSD source code from 1988, and OpenBSD inherited the type without increasing its size. The exploit attaches 127 shared-memory segments and creates 259 processes, forcing the counter beyond its limit so that it wraps to a negative value of -32,643.
A race condition, in which the result depends on the timing of simultaneous operations, then turns the corrupted counter into a use-after-free. The kernel releases memory even though other processes are still using it. A separate out-of-bounds write, meaning data is written beyond the memory area assigned to it, alters counters associated with multicast network memberships. When the affected socket closes, subsequent counter reductions modify page-table entries, the records that control how memory is mapped and accessed.
Those changes make a user-memory mapping accessible in supervisor mode and defeat Supervisor Mode Access Prevention (SMAP) and Supervisor Mode Execution Prevention (SMEP). The exploit can then replace a function pointer, a stored address telling the system which code to run, at a predictable kernel location and execute its own code with root privileges. Because this is a local privilege escalation, it does not by itself provide a remote route into a system. It becomes relevant when someone already has the ability to run code or use an account on an unpatched OpenBSD host.
OpenBSD's KARL mechanism relinks the kernel at boot to change the locations of functions and data. Calif found that the memory allocators responsible for assigning kernel memory remain deterministic. Neither the early boot allocator nor the best-fit allocator randomizes its base address. As a result, structures created early in startup, including function pointers used by the lo0 and enc0 network-interface handlers, appear at the same addresses after repeated restarts on the same hardware. The demonstrated chain therefore does not need an information-disclosure vulnerability to reveal kernel addresses first.
Beyond installing the two errata, Calif proposed four broader hardening measures: safe-unlinking checks for kernel linked lists, already used by FreeBSD and NetBSD; randomizing the self-referential page-table mapping; adding randomization to kernel memory allocation; and using compiler-based bounds checking to detect memory access outside permitted limits. These are proposed defenses rather than fixes described as already present in OpenBSD.
For hosting providers and businesses running OpenBSD infrastructure, the immediate action is to use syspatch and confirm that the applicable September corrections are installed on every affected system. Administrators should also review which users and services are allowed to execute local code, because the published exploit requires local access before it can elevate privileges. Organizations reviewing the security of OpenBSD-based environments can use AEU-I for security-first IT, infrastructure and consulting.