A 37-year-old counter bug gives local root on OpenBSD 7.9

OpenBSD has a reputation as one of the most hardened operating systems available, so a working local root exploit against it gets attention. Security firm Calif has published a full write-up and proof-of-concept that turns an ordinary local account into root on OpenBSD 7.9. The chain gets past the kernel's address relinking (KARL) and the CPU's SMAP and SMEP protections. Both bugs are already fixed, and the patches can be installed with syspatch.

What happened

The chain uses two flaws:

An integer overflow in shmat(4) that dates back to 1988. The counter that tracks how many processes have a shared-memory segment attached (shm_nattch) is a signed 16-bit short, so its maximum is 32,767. OpenBSD inherited that type from the original BSD sources and never widened it. When a process attaches enough segments and forks enough children (127 segments and 259 processes in the PoC), the counter wraps negative. A race then turns that into a use-after-free: the kernel frees memory that other processes are still using.
A separate out-of-bounds write that corrupts multicast-membership counters. When the affected socket closes, the resulting decrements change page-table entries. That flips a user-memory mapping to supervisor-accessible, which is how the exploit gets around SMAP and SMEP. It then overwrites a function pointer at a predictable kernel address to take control.

The key point is about predictability. KARL relinks the kernel binary on every boot, but the kernel's memory allocators remain deterministic. Early-boot structures, including function pointers in the lo0 and enc0 network-interface handlers, end up at the same addresses on the same hardware after every reboot. As a result, the exploit doesn't need a separate information-leak bug.

Patch status

The shmat(4) integer overflow was fixed in errata 018 (September 14), which was published as a reliability fix rather than a security fix.
The use-after-free that completes the chain was fixed in errata 026 (September 30) as a security fix.
Both fixes cover all architectures and are available through syspatch. OpenBSD 7.8 also received the integer-overflow fix.
No CVE had been assigned to either flaw at the time of writing, and there is no evidence of exploitation in the wild.

Why it matters

This is a local privilege-escalation bug, so an attacker first needs to run code on the box. That still matters on shared hosts, jump boxes, firewalls with shell users, and any system where one compromised service could become a full takeover. Two details deserve a second look:

A "reliability" errata turned out to be part of a root chain. Teams that only apply patches labelled as security fixes would have skipped errata 018.
Exploit code is public. With a working PoC on GitHub, the time before others adapt it has largely run out.

Calif also suggests four hardening directions for the kernel: safe-unlinking for linked lists (as FreeBSD and NetBSD already do), randomizing the page-table self-referential mapping, randomizing kernel allocators, and compiler-level bounds checking.

What to do

Run syspatch on every OpenBSD 7.9 host now, and confirm that errata 018 and 026 are applied. On 7.8, check the integer-overflow fix too.
Apply reliability errata as well. Treat every errata as potentially security-relevant, not only the ones marked as security fixes.
Reduce local attack surface. Review who has shell access on firewalls, routers and bastion hosts, and remove accounts and services that aren't needed.
Inventory your BSD estate. OpenBSD boxes often sit at the network edge and get patched less often than the main fleet. Make sure each one is tracked.

Knowing which hosts in a mixed estate are still running unpatched builds is exactly what our vulnerability scanning service does. It flags outdated OS and kernel patch levels, so a bug like this gets fixed before it shows up in an incident report.