A centuries-old piece of OpenBSD’s original BSD kernel code recently revealed a critical set of vulnerabilities that could be chained for root access. Security firm Calif released proof-of-concept exploit code on October 16, 2026, demonstrating how two long-existing flaws—one nearly 37 years old—were combined in a local privilege escalation exploit. The issues have since been patched before the PoC’s public release.
Deep in the Kernel: Shared Memory Counters and Integer Overflow
The root cause lies in System V shared memory handling, specifically in the `shm_nattch` counter: a signed 16-bit integer tracking how many processes have attached to a shared memory segment. Under OpenBSD’s old behavior, each forked process incremented this counter. Once it exceeds its maximum of 32,767, it wraps around to a negative value. That triggers unexpected behavior, creating an integer overflow and enabling a race condition that leads to use-after-free in kernel memory. Calif researchers documented that flaw as the first half of the exploit chain.
Out-of-Bounds Write Leads to Root Access
The second flaw allows a conditional out-of-bounds write, which the researchers exploited to gain write access in kernel memory. Their PoC maps 127 shared memory segments, strips their mappings, and forks 259 processes to force the overflow. After shaping the kernel heap and inspecting allocator state, they win a precise race between removing a shared memory segment and attaching a replacement. That race creates a “size confusion,” freeing memory incorrectly and allowing nearby IP socket objects to be placed in the freed space. The exploit then corrupts internal socket structs via `IP_MULTICAST_TTL`, tampers with page-table mappings, and bridges user-space to kernel-mode. From there, a user-space process overwrites a kernel pointer and invokes code that opens a root shell—despite modern protections such as KARL, SMAP, and SMEP remaining active.
Patching the Old Flaw and Moving Forward
OpenBSD has already applied fixes. The integer overflow was resolved in Errata 018, and the associated use-after-free was addressed in Errata 026. These updates apply across amd64, i386, and arm64 architectures via the 7.9 errata. Administrators are urged to apply all available patches using `syspatch` and reboot their machines to load the corrected kernel.
Calif also proposed additional safeguards to prevent similar long-dormant flaws: adding safe unlink checks for linked lists, making page-table maps randomly placed, reducing predictability in kernel allocations, employing array bounds checking in compilers, and isolating allocations more strictly.
Why a Decades-Old Bug Stayed Hidden
Part of the vulnerability’s stealth came from its age. The `shm_nattch` counter was part of legacy shared memory tracking, a routine mechanism in older Unix systems. Because its behavior wasn’t clearly broken until specific, complex conditions—many processes, shared memory segments, race windows—it eluded detection for almost four decades. The exploit works without any information leak, which makes discovering similar bugs harder for routine audits.
The researchers say they found no evidence that this exploit has been used in the wild. Still, the risk in environments where local access is possible—such as shared systems, multi-user servers, or supply-chain environments—could be serious.
This incident underscores how early architectural decisions in core operating systems can survive for decades and turn into security liabilities. Even with modern mitigations enabled, predictable allocator behavior or stable early boot memory objects can give attackers footholds if they carefully map the path.
What to Watch: any OpenBSD system running version 7.9 or earlier without the latest errata is potentially vulnerable. Critical services, particularly those allowing unprivileged local users (containers, shared hosting, academic machines), need to be updated. Watch for third-party dependencies or custom kernel builds—if they don’t include ERRATA 018 and 026, they may still carry the old flaws. The MAD Bugs project’s public PoC could help defenders test their environments, but also arms potential attackers. The balance of disclosure and preemptive patching remains as important as ever.
