A bug that has quietly ridden along in BSD-derived kernel code for roughly 37 years has finally been turned into a working root exploit on OpenBSD. Security researchers at Calif published proof-of-concept code on October 16, 2026, after OpenBSD shipped fixes for both flaws in the chain — and after confirming the chain works even with the operating system’s modern exploit mitigations switched on.

A Counter That Was Never Meant to Overflow

At the center of the bug is a tiny design choice from the earliest days of BSD System V shared memory support: the counter tracking how many processes are attached to a shared memory segment, shm_nattch, was implemented as a signed 16-bit integer. That gives it a maximum value of 32,767 — a limit nobody expected a local, unprivileged user to ever reach on purpose.

Calif’s researchers did exactly that. By rapidly forking processes that each attach to shared shared-memory segments, they pushed the counter past its ceiling, where it silently wraps around into negative territory. That integer overflow opens the door to a race condition that triggers a kernel use-after-free — memory the kernel still thinks is in use, freed while something else can still reach it.

Turning Memory Corruption Into Root

An overflow alone isn’t an exploit. The researchers paired it with a second flaw: a conditional out-of-bounds write that gave them just enough control over corrupted memory to engineer a reliable escalation path. Their published technique maps 127 shared memory segments, strips their mappings, and forks 259 processes in a carefully timed sequence to force the counter to wrap on demand, while watching the kernel’s memory allocator behavior through a sysctl call to steer the timing.

From there, one process marks a shared memory object for deletion while a second races to attach a fresh segment at precisely the right moment. Winning that race produces a kernel allocation that is confused about its own size. The researchers then position IP socket objects — manipulated via a multicast TTL option — next to the corrupted memory, using the out-of-bounds write to tamper with internal membership counters inside the resulting data structure.

Closing that socket sets off a chain of atomic counter operations that ultimately corrupt OpenBSD’s self-referencing page-table mapping, a structure the kernel relies on to manage its own memory. The result: a user-space memory mapping becomes visible to supervisor-mode code, letting the exploit overwrite a kernel pointer, execute arbitrary code in kernel context, quietly repair the pointer it damaged along the way, and hand back a root shell.

Mitigations Weren’t Enough

What makes this chain notable is that it succeeded without needing a separate information leak, despite running against a system with KARL, SMAP, and SMEP all enabled — protections specifically designed to randomize and restrict kernel memory access. KARL randomizes kernel code and data locations at every boot, but Calif found that portions of the kernel’s memory allocator still land in predictable locations on identical hardware, letting the exploit reliably target specific ioctl handler pointers tied to the loopback and encapsulation network interfaces.

Patches Are Already Out

OpenBSD closed the integer overflow in Errata 018 and the use-after-free in Errata 026, both listed on the OpenBSD 7.9 errata page and distributable as binary updates through syspatch on amd64, i386, and arm64 systems. The fixes were live before Calif’s public disclosure, and the group has stated it found no evidence the chain had been used in real-world attacks before publication.

Administrators running OpenBSD should treat this as a priority patch regardless: apply every pending errata update and reboot so the corrected kernel is actually running, rather than just installed.

A Pattern Worth Watching

• Apply OpenBSD Errata 018 and 026 via syspatch and reboot affected systems.
• Don’t rely on address-space randomization alone — Calif’s research shows allocator behavior can still be predictable even with KARL active.
• Review any legacy System V IPC code your own systems still depend on for similarly dated signed-counter designs.
• Treat local privilege escalation bugs in shared infrastructure code as high priority, even without evidence of in-the-wild exploitation.

Calif has also proposed broader structural defenses, including safer unlink checks for kernel linked lists and less predictable placement of memory-allocator data — changes that would make this style of memory-corruption bug considerably harder to weaponize in the first place. The research adds to a small but growing list of decades-old OpenBSD flaws resurfacing in 2026, following earlier disclosures of a 27-year-old authentication bug and a separate NFS double-free issue, a reminder that code trusted for generations can still be hiding exploitable assumptions nobody thought to question.