A vulnerability dating back nearly four decades has resurfaced in OpenBSD, this time as part of an exploit chain capable of giving a local attacker root privileges. Security researchers at Calif demonstrated how an integer overflow in the operating system’s shared-memory handling could be combined with other kernel weaknesses to bypass several of OpenBSD’s security protections.
The research targets OpenBSD 7.9 and shows that even long-established operating systems with a strong focus on security can carry weaknesses inherited from much older code.Calif published its technical findings alongside a working proof-of-concept exploit after the OpenBSD development team released patches in September 2026.
Two Kernel Bugs Behind the Exploit
The attack relies on two vulnerabilities that were addressed in separate OpenBSD security updates.
The first involves an integer overflow in the shmat(4) shared-memory attachment mechanism. OpenBSD fixed this issue on September 14 through errata 018, categorizing it as a reliability problem rather than a security vulnerability.
The second issue is a reference-counting error that can lead to a use-after-free condition in the kernel. This was resolved on September 30 under errata 026, which OpenBSD classified as a security fix.
Both patches are available through OpenBSD’s syspatch utility and apply across supported architectures. OpenBSD 7.8 also received a fix for the integer overflow. Neither vulnerability had received a CVE identifier at the time of publication, and researchers have not reported evidence of exploitation in the wild.
A Problem Hidden in BSD Code Since 1988
One of the more interesting findings is how far back the underlying problem goes. The shared-memory attachment counter, shm_nattch, was originally defined as a signed 16-bit integer in BSD source code dating to 1988. That data type can represent values only up to 32,767. Despite decades of development, OpenBSD retained the original definition. Under normal conditions, this limitation might never become noticeable. However, the researchers found a way to push the attachment counter beyond its supported range.
Their demonstration creates 127 shared-memory segments and forks 259 processes, causing the counter to overflow and wrap around to a negative value of −32,643. That corrupted counter becomes particularly dangerous when combined with a race condition. The kernel can mistakenly release memory that is still being referenced elsewhere, creating a use-after-free condition. What began as an old integer-size limitation ultimately provides the starting point for a much more serious kernel exploit.
How the Attack Gets Around OpenBSD’s Defenses
Exploiting the shared-memory bug alone is not enough to obtain root access. The researchers built a chain involving additional memory corruption to reach that goal. A separate out-of-bounds write allows the exploit to interfere with multicast membership counters inside the kernel. When the affected socket is closed, changes to those counters can alter page-table entries.
This manipulation makes it possible to change memory-access permissions and undermine two hardware-based protections:
- SMAP (Supervisor Mode Access Prevention): Designed to prevent the kernel from accessing user-space memory unexpectedly.
- SMEP (Supervisor Mode Execution Prevention): Prevents the kernel from executing instructions located in user-space memory.
By manipulating page-table permissions, the exploit can make attacker-controlled memory accessible in a way that defeats these protections. The researchers then take advantage of predictable kernel memory locations to overwrite a function pointer and redirect execution to their own code. The result is a local privilege escalation from an unprivileged process to root.
Why Kernel Address Randomization Wasn’t Enough
OpenBSD uses a security mechanism called KARL (Kernel Address Randomized Link), which changes the arrangement of kernel functions and data during the boot process. The idea is to make it harder for an attacker to predict where important kernel components are located in memory. However, Calif found that KARL does not randomize every part of the kernel’s memory layout.
In particular, the kernel’s boot-time and best-fit memory allocators behave predictably. Certain structures allocated early during startup can therefore appear at consistent memory addresses across reboots on the same hardware. This includes function pointers associated with the lo0 loopback interface and the enc0 network interface. That predictability matters because attackers normally need some way to discover kernel addresses before they can reliably redirect execution. In this case, the researchers demonstrated that an additional information-disclosure vulnerability was unnecessary. KARL still provides protection, but the research highlights a limitation: randomizing kernel code does not eliminate predictable memory layouts elsewhere in the system.
Researchers Recommend Additional Kernel Hardening
Beyond identifying and reporting the vulnerabilities, Calif outlined several improvements that could make similar attacks more difficult in the future. The recommendations include introducing safe-unlinking protections for kernel linked lists, an approach already used by FreeBSD and NetBSD. The researchers also suggested randomizing the self-referential page-table mapping and introducing more randomness into kernel memory allocation. Another recommendation involves compiler-assisted bounds checking to catch certain memory-access errors before they can be exploited. These changes would not necessarily eliminate every possible kernel vulnerability, but they could make memory corruption harder to turn into a successful privilege escalation.
Patches Are Available
Calif reported the vulnerabilities to the OpenBSD developers earlier in 2026. Both issues were subsequently patched before the research and exploit code were made public. Administrators running affected OpenBSD installations should ensure the relevant security and reliability updates have been installed. On supported installations, available binary patches can be applied using:
doas syspatchA reboot may be required for kernel updates to take effect. Although the researchers have released working proof-of-concept code, there is currently no publicly reported evidence of these vulnerabilities being exploited in real-world attacks. The case is a reminder that security problems do not always originate in newly introduced code. Sometimes, a seemingly harmless implementation decision can survive for decades before someone discovers how to turn it into a practical attack. For OpenBSD, the immediate vulnerabilities have been addressed. The broader questions raised by the research concern how older kernel code interacts with modern memory protections, and where additional hardening could reduce the impact of future bugs.
References
- Calif Security Research — Big Fish
- OpenBSD 7.9 Errata and Security Updates
- Original BSD Shared Memory Header
- Calif Proof-of-Concept Repository
- Exploit Demonstration on YouTube
I’m Ryan, a Network Engineer from Indonesia focused on network infrastructure, Server Management, and system administration, with a background in network security and cybersecurity. I enjoy building, troubleshooting, and understanding complex systems from the ground up.