- Calif chained a roughly 37-year-old counter overflow with a second kernel flaw to gain root on OpenBSD. Patches shipped in errata 018 and 026.
- The Hacker News reports one fix was labelled a reliability fix. The sources disagree on which errata fixed the integer overflow.
- Confirm syspatch is applied on any OpenBSD systems, and ask how your teams treat patches that carry no security label.
Two OpenBSD patches, released two weeks apart, close the holes behind a new root exploit. According to The Hacker News, the first was filed under reliability rather than security. The sources disagree on which flaw that patch covered. The question still matters. A patch that looks minor on its own can be one link in a chain, and triage that judges each fix alone may miss it.
What Calif found
Calif, a security firm, reported two kernel flaws to OpenBSD earlier this year. It has now published a writeup and, according to The Hacker News, full proof-of-concept code. Chained together, the flaws give a local user root on a system with OpenBSD's kernel-address randomization (KARL) and the hardware protections SMAP and SMEP switched on. Calif says the exploit needs no information-disclosure bug.
The attacker must already be able to run code on the machine. This is a privilege escalation, not a remote break-in. OpenBSD fixed the issues in errata 018 and 026. The Hacker News reports both are available through syspatch, that no CVE has been assigned to either, and that there is no evidence of attacks.
How the chain works
The first flaw is a counter. It tracks how many times a piece of shared memory is attached. Calif says the original BSD sources defined it as a signed 16-bit number, which tops out at 32,767. Push past that and the value wraps around to a negative number.
The exploit does exactly that. It maps 127 shared-memory segments, then forks 259 processes. The counter wraps to -32,643. A race condition then turns the corrupted count into a use-after-free, where the kernel frees memory that something else still uses.
A second flaw, an out-of-bounds write, overwrites two counters in a small network-socket structure. Closing the socket triggers decrements that edit the page tables. Those tables control which memory user programs may touch. The edit turns a user-controlled memory mapping into one the kernel treats as its own, which defeats SMAP and SMEP.
To finish, the exploit corrupts a stored function address in a spot it can count on finding. Calif says it targets the handlers for two network interfaces, lo0 and enc0. It overwrites one to take control and uses the other to put the original back.
That spot is the gap in the randomization. Researcher Andrew Griffiths wrote that KARL randomizes function and data addresses, but "the kernel's memory allocators remain deterministic." Early-boot structures land in the same places across reboots on the same hardware.
Labels describe single bugs, attackers use chains
The Hacker News dates errata 018 to September 14 and says it went out as a reliability fix, even though it addresses the integer overflow where the attack begins. The same outlet says errata 026, released September 30, closed the use-after-free and was issued as a security fix.
Calif's account differs in part. Both sources agree the use-after-free was fixed in errata 026. They disagree on the overflow: The Hacker News places its fix in 018, while Calif places it in 026. Calif ties 018 to the out-of-bounds write. Which flaw sat behind the reliability label therefore depends on which account is right. The OpenBSD errata notices are not among the sources used here.
The lesson holds either way. According to The Hacker News, one patch in the pair was not presented as a security fix, and the exploit needs both. A triage process that asks only whether each fix is a security issue could miss a chain like this. That is this article's argument, not a finding from either source.
The second lesson is about randomization. KARL was working as designed. The weakness sat in a layer it did not cover. Defences that shuffle one part of a system leave attackers looking for the part that stays still.
Fixing classes, not instances
Calif does not stop at the two errata. It proposes safe-unlinking for kernel lists, which FreeBSD and NetBSD already use. It also proposes randomizing the page-table mapping, randomizing the kernel allocator, and compiler-based bounds checking.
On bounds checking, Calif says it privately reported 21 issues to FreeBSD that an array bounds sanitizer would have caught. Some had local privilege escalation impact.
Calif also ties its advice to AI. It says AI-assisted bug hunting makes broad defences, which remove whole categories of flaw, more valuable. That is Calif's view, and the writeup offers no data on AI-found flaws.
What to ask your team
If your organisation runs OpenBSD, for example on firewalls or gateways, confirm that syspatch has applied errata 018 and 026. The Hacker News reports both cover all architectures.
For everything else, put three questions to your security lead. Do fixes labelled reliability or stability get a security look before they are deferred? How fast do patches reach systems where users can run their own code? Which of our defences rely on one layer of randomization?
A 37-year-old counter did not need to be clever to matter. It needed a neighbour. Patch triage should read each fix with that in mind.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Calif (calif.io).
