A local privilege escalation published against OpenBSD 7.9 gets root by chaining a roughly 37-year-old integer overflow in shared memory with a second kernel flaw. Security firm Calif reported both bugs, waited for the patches to land, then published a full proof-of-concept that bypasses KARL kernel-address randomization and Intel’s SMAP and SMEP protections. If you treat OpenBSD as the quiet packet filter in front of everything else, this is the cybersecurity problem that should rearrange your week.

shm Integer Overflow Chained With Second Kernel Flaw for Root

Calif’s writeup is blunt about the construction. One bug is an integer overflow in shared-memory handling that has been sitting in the Unix-shaped part of the kernel since the late 1980s. The second is a separate kernel flaw that turns that corruption into a reliable privilege climb. Together they produce root on OpenBSD 7.9. The researchers also showed the chain getting around KARL, which relinks the kernel at boot so gadget addresses should not be stable, and around SMAP and SMEP, the CPU features meant to stop kernel code from touching or executing user memory.

Your threat detection stack will miss this if it is still tuned for noisy brute-force logins and malware hashes. The chain is local. Someone already has a process on the box: a popped daemon, a shared hosting tenant, a CI user you allowed to build, a support login that should never have had a shell. From there, the published proof-of-concept is a recipe. Calif held the code until OpenBSD shipped the fixes. Anyone who skipped those fixes is running a documented path to kernel control.

OpenBSD’s usual answer to this class of research is fast errata and a community that actually installs syspatch. That culture is real. It does not help the firewall image you cloned 14 months ago, or the mail gateway whose upgrade window keeps slipping because it is “stable.” Those hosts are where this lands.

KARL, SMAP, and SMEP Bypassed in the Published Root Chain

A quarter-million-dollar Chrome exploit made this week’s under-the-radar roundup. So did Bank of America hiring about 1,000 contractors to help with patching. Both facts tell you how the rest of the industry is spending money: browsers and CVE volume. The OpenBSD chain is free, public, and aimed at the operating system a lot of teams still use as a threat-protection boundary.

You already drop brute-force noise at the edge. Keep doing that. This chain starts after that fight is over, when some user process is running and shared-memory syscalls are legal. You put pf in front of the estate because the code is audited and the default install is small. Fair. Hardware mitigations and kernel relinking were supposed to make residual memory bugs expensive. Here they were bypassed in a published chain. Defense in depth on a bastion has to assume that a network-facing process plus local code execution equals kernel control, even on the OS you picked to avoid that outcome.

Shared-memory primitives are glue. Databases, daemons, and older Unix services still use them. An overflow in that glue is the kind of bug scanners skip because the box is labeled “network device” in the asset database and the OS string is not in your enterprise Linux SKU. Your cyber security inventory probably lists the branded appliances and the cloud load balancer. It often forgets the OpenBSD VPN concentrator in the colo that has been up since the last hardware refresh. This is a bad look for teams that treat OpenBSD uptime as a substitute for patch evidence.

Cybersecurity Containment Steps for Exposed OpenBSD Firewalls

Start tonight, not after the next change-advisory board. The exploit is local, so your remaining luck is that nobody with a process on the box has run the published chain yet. Treat every OpenBSD firewall, VPN terminator, mail relay, and jump host as in-scope, including the forgotten colo unit and any OEM image that still reports 7.9.

• Inventory OpenBSD packet filters, VPN concentrators, mail gateways, and jump hosts, including vendor appliances and gold images still on 7.9.
• Install the shipped errata with syspatch or a rebuilt image, then verify the running kernel matches the fixed build.
• Remove compilers, extra shells, and leftover admin accounts from bastions so a compromised daemon has less to work with.
• Confine network services to dedicated users and the tightest filesystem and syscall restrictions the OS already offers.

After the emergency window, put these hosts on the same patch SLA you already use for Windows and Linux. Security hardening here is boring on purpose: smaller images, fewer packages, no debug toolchains, and configuration stored in a repo so you can rebuild instead of “healing” a box that may already be rooted. If a daemon on that host is reachable from a network you do not fully control, write the playbook as if that daemon’s RCE is kernel compromise. You do not get a second containment layer from KARL after this research.

Keep logs off the box. Root owns local syslog. Forward auth, pf, and process-accounting records to a collector the bastion cannot rewrite. Review which keys, tunnels, and management jump paths traverse that host, because those secrets are the blast radius. Revisit service accounts quarterly. The machine you never SSH into is still a machine that can initiate connections once someone else is root.

Incident Response When the Packet Filter Host Is Already Root

If you find a 7.9 box that missed the errata, run incident response even if nobody has filed a ticket. Isolation first: stop using it as a trust anchor. Do not just reboot and declare it clean. A kernel-level chain can leave you with a lying runtime. Snapshot what you can, stand up a known-good replacement, and rotate every credential that landed on or passed through the old host, including VPN PSKs, SSH keys, and mail credentials.

Hunt for extra users, unexpected setuid binaries, new pf rules, and outbound sessions you cannot explain. Compare running processes against your gold image. If you lack that image, you are guessing, and guessing is how persistent local root survives a “we patched it” update. Off-box logs are the only records you should trust once kernel write primitives were in play.

Bank of America’s thousand contractors are a reasonable reaction to patch volume on a sprawling estate. They do not help if the OpenBSD systems sit outside the scanner because someone labeled them network gear. Put those hosts in the same queue as everything else that can mint packets on your behalf. The $250k Chrome bug is someone else’s bounty. Your copy of this chain is already on the internet.

Sources

• Researchers Demonstrate OpenBSD Root Exploit Chaining 37-Year-Old Shared-Memory Bug
• In Other News: ICS-Sniper Attack, Hacking XWorm Malware Operators, $250k Chrome Exploit