TL;DR
Get business pricing on networking and server gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
Security research firm Calif reported that a signed 16-bit shared-memory attachment counter, traceable to original BSD source code about 37 years ago, could overflow in OpenBSD. Calif says it combined the resulting race and use-after-free with a separate out-of-bounds write to gain local root access; OpenBSD addressed the issues in errata 026 and 018.
Security research firm Calif has described an OpenBSD exploit that used a 37-year-old shared-memory accounting bug alongside a separate kernel out-of-bounds write to obtain local root access. Calif says the issues were addressed in OpenBSD errata 026 and 018; its report explains how the bugs could be combined even with several kernel protections enabled.
The older flaw involved shm_nattch, a shared-memory attachment counter defined as a signed 16-bit short in code traceable to the original BSD sources. Calif says repeated process forking could drive the counter beyond its maximum positive value of 32,767, wrapping it to a negative number. In the reported exploit, that accounting error contributed to a race condition and a use-after-free in the kernel.
Calif combined that flaw with a separate out-of-bounds write. The company says the chain let it alter kernel memory and achieve local privilege escalation to root. Its account describes testing against OpenBSD with KARL, SMAP and SMEP enabled, and says the exploit did not rely on an information-disclosure vulnerability. These are claims from the researchers’ technical report, not an independently documented reproduction in the supplied material.
The report outlines a sequence involving System V shared-memory segments, process creation, heap placement and a race between removing and attaching memory segments. It says the out-of-bounds write altered fields in a network socket structure; later kernel operations then changed access to a page-table mapping and enabled control-flow manipulation. Calif says it restored an overwritten kernel pointer during cleanup before obtaining a root shell.
How the Exploit Reached Root
The report matters because it shows how separate kernel weaknesses can reinforce one another: an old counter overflow helped create unsafe memory handling, while another bug supplied a write primitive. Calif’s account says the chain worked despite protections intended to make kernel exploitation harder, underscoring that mitigation layers do not necessarily prevent a carefully combined local exploit.
Calif also points to a limitation in kernel address randomization. It says OpenBSD’s KARL relinks the kernel binary, but allocator behavior can still leave some early allocations at predictable locations on the same hardware. Predictable structures containing function pointers may provide targets. The researchers propose possible defenses, including safe-unlink checks, randomizing the recursive page-table mapping, and reducing allocator predictability. These are proposals in the report, not confirmation that OpenBSD has adopted them.
For users and administrators, the direct practical point is to consult the relevant OpenBSD errata and apply fixes appropriate to their release. The described chain requires local execution, according to Calif’s account; the report does not establish remote exploitation or widespread attacks.
As an affiliate, we earn on qualifying purchases.
From BSD Source to OpenBSD Errata
Calif says it reported vulnerabilities to OpenBSD earlier this year, in some cases with suggested patches. It traces the shared-memory counter’s signed-short definition to original BSD source code roughly 37 years ago. That history describes the age of the code pattern, not necessarily how long the vulnerability was known or exploitable in every intervening system.
The report distinguishes two issues: the shared-memory counter problem and the separate out-of-bounds write used in the exploit chain. Calif says they were handled through errata 026 and 018, respectively. The supplied source does not include the errata publication dates, affected release ranges, or the exact patch details, so those specifics cannot be established from the report excerpt alone.
Calif’s broader mitigation discussion includes changes that could make similar exploit techniques harder, such as validating doubly linked list operations before unlinking entries and randomizing allocator placement. The company also mentions compiler array-bounds checks as a potential way to catch certain out-of-bounds accesses. Those suggestions are separate from the stated errata fixes.
“One traced back roughly 37 years to the original BSD sources, where a shared memory attachment counter was defined as a signed 16-bit short.”
— Calif, in its research report
As an affiliate, we earn on qualifying purchases.
Questions the Report Leaves Open
The supplied report does not identify the affected OpenBSD releases, give the errata dates, or reproduce the full patch notes. It also does not provide independent testing or confirmation from OpenBSD maintainers. Calif’s exploit description is detailed, but the source material alone does not establish whether the same chain works on other hardware configurations or versions.
It is also unclear whether OpenBSD has implemented any of Calif’s additional mitigation proposals, including safe-unlinking or allocator and page-table-map randomization. The report presents these as possible defenses rather than changes already in place. No evidence in the supplied material indicates that the vulnerability was exploited in real-world attacks.
As an affiliate, we earn on qualifying purchases.
Check Errata and Patch Status
OpenBSD users should check the project’s errata 026 and 018 for affected versions and remediation instructions, then apply the relevant fixes. Calif’s report also gives maintainers potential areas for further review, including linked-list integrity checks and the predictability of kernel allocations.
The next concrete information for readers would be the errata’s release-specific details and any OpenBSD maintainer response on the proposed broader mitigations. Until those details are confirmed, the reported exploit should be understood as Calif’s account of a local privilege-escalation chain, with the stated fixes distinguished from its suggested future defenses.
privilege escalation testing tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Key Questions
What was the old OpenBSD bug?
Calif describes a signed 16-bit shared-memory attachment counter that could overflow when repeated process activity pushed it above 32,767, causing it to wrap to a negative value.
Did the counter bug alone give attackers root access?
According to Calif, the exploit combined the counter issue and resulting memory-management race with a separate out-of-bounds write. The report does not describe the counter flaw as the sole component of the full chain.
Was the exploit remote?
Calif describes it as a local privilege-escalation exploit. The supplied material does not show that the chain could be triggered remotely.
Were the issues fixed?
Calif says the issues were addressed in OpenBSD errata 026 and 018, respectively. The source provided here does not specify affected releases or patch instructions, so users should consult the errata directly.
Has OpenBSD adopted the additional mitigations Calif proposed?
The report lists safe-unlinking, page-table-map randomization and allocator randomization as possible defenses. It does not confirm that OpenBSD implemented them.
Source: hn
Halloween Picks
halloween
As an affiliate, we earn on qualifying purchases.
