Technology · NEWS EXPLAINER
OpenBSD “Big Fish” exploit gets local root—but patches were already available
Calif published a working OpenBSD 7.9 local privilege-escalation chain on October 16. It combines a decades-old shared-memory counter overflow with other kernel bugs; OpenBSD had already shipped the relevant fixes in September.
Security firm Calif published a complete proof of concept on October 16 showing local privilege escalation to root on OpenBSD 7.9. The chain starts with a signed 16-bit shared-memory attachment counter that can wrap after enough mappings and forks, then combines a race-triggered use-after-free with a separate out-of-bounds write.
The demonstration is serious, but its boundary matters: an attacker first needs the ability to run code as a local user. The writeup does not demonstrate an unauthenticated remote compromise. OpenBSD had already issued errata 018 on September 14 and errata 026 on September 30, before the public exploit code appeared.
What the public exploit demonstrates
Calif says the exploit maps 127 System V shared-memory segments and forks 259 processes, pushing the attachment counter past its signed 16-bit maximum. A race then turns the corrupted accounting into a use-after-free.
The chain uses heap grooming and a separate out-of-bounds write to alter page-table state and overwrite a predictable kernel function pointer. The researchers report a root shell with KARL, SMAP and SMEP enabled and without an information-disclosure bug.
What it does not demonstrate
This is local privilege escalation. The published path assumes an attacker can already execute code as an unprivileged user on the machine. It does not, by itself, provide a network-facing or unauthenticated route into an OpenBSD host.
No CVE had been assigned and no exploitation in the wild had been reported when the independent coverage was published. Those absences are a point-in-time status, not proof that exploitation cannot occur after public code release.
The fixes arrived before the proof of concept
OpenBSD 7.9 errata 018, dated September 14, prevents the shmat(4) integer overflow. Errata 026, dated September 30, fixes a kernel reference-counting bug that could lead to use-after-free. Both official entries cover all architectures at source level.
The errata page says binary updates are available through syspatch for amd64, i386 and arm64, while other architectures may need source-based stable-branch handling. OpenBSD 7.8 separately received the shared-memory overflow fix as errata 054.
How administrators can verify protection
On an official supported OpenBSD release, running syspatch with no options fetches, verifies and installs all missing binary patches; patches are cumulative and cannot be selected individually. The -c option lists available patches and -l lists installed patches.
Do not infer protection only from the operating-system version string. Verify installed patches, read the command output and follow any restart or reboot instruction supplied by the patch. Systems on unsupported releases or architectures without the needed binary update should use the project’s signed source patch and supported -stable guidance.
Why the research still matters after patching
The 37-year-old counter type is only the opening step. The exploit also depends on deterministic kernel allocations and another memory-corruption primitive. Calif proposes safe unlinking, page-table mapping randomization, allocator randomization and compiler bounds checking to raise the cost of similar chains.
For readers, the practical conclusion is narrow: patch verification is urgent now that a working chain is public, but the research should not be described as a remote OpenBSD takeover or evidence of active attacks.
