Skip to content

Public PoC roots OpenBSD 7.9 via a 37-year-old shmat bug

Calif published a full OpenBSD 7.9 local-root exploit chaining a 1988-era shmat integer overflow with a kernel use-after-free, bypassing KARL, SMAP and SMEP. No CVE assigned.

Published 3 min read

Security firm Calif has published a working local-privilege-escalation exploit that gets root on OpenBSD 7.9, chaining an integer overflow inherited from 1988-era BSD shared-memory code with a kernel use-after-free. The write-up ships with full proof-of-concept code. OpenBSD already fixed both bugs via errata in September, so the action is simple: run syspatch. There is no evidence of exploitation in the wild, but the PoC is public now.

The primary source is Calif's write-up, Big Fish: Exploiting a 37-Year-Old Kernel Bug in OpenBSD by Andrew Griffiths, with code at github.com/califio/publications. OpenBSD's fixes are on the 7.9 errata page.

The bugs

  • Integer overflow in shmat(4). The shared-memory attach counter shm_nattch is a signed 16-bit short, a type carried forward from 1988 BSD sources. Repeatedly attaching a segment pushes the counter past 32,767 and wraps it negative, which Calif turns into a use-after-free via a race.
  • Reference-counting use-after-free in the kernel. The underlying System V IPC reference-counting bug lets the kernel free memory other processes still hold.

Calif's chain reaches root without an information-disclosure primitive, and the write-up details how it bypasses OpenBSD's KARL kernel-address randomization along with the SMAP and SMEP hardware protections — defenses that normally make this class of bug far harder to weaponize. No CVE has been assigned to either flaw as of publication.

The patches

OpenBSD shipped both fixes as 7.9 errata, installable through syspatch on all architectures:

  • Erratum 018 — "Prevent integer overflow in shmat(4)," dated September 14, 2026, classified as a reliability fix.
  • Erratum 026 — "A reference counting bug could lead to use-after-free in the kernel," dated September 30, 2026, classified as a security fix.

The timing matters: the overflow was shipped as a reliability fix two weeks before the use-after-free was flagged as a security issue, so a system patched only against the earlier erratum was still exploitable.

Action checklist

  1. Run syspatch on OpenBSD 7.9 hosts and confirm errata 018 and 026 are applied. syspatch -l lists what's installed.
  2. Prioritize multi-user and shell-access boxes. This is local privilege escalation — the risk is highest where untrusted users already have a local account (shared shells, CI runners, jump hosts).
  3. Treat the PoC as live. The exploit source is on GitHub; defenders and red teams can both run it, so an unpatched 7.9 host should be considered rootable by any local user.

Context

OpenBSD's security reputation rests on exploit mitigations like KARL, SMAP and SMEP, so a no-infoleak root chain that walks through all three is notable on its own — and it came out of a signedness bug old enough to predate the project. Calif's write-up is a reminder that "mitigations present" is not "mitigations sufficient," and that a reliability-tagged erratum can quietly be the first half of a security fix. The practical takeaway is unglamorous: patched is patched, and this one is a one-command fix.

Related stories