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 an OpenBSD kernel bug dating to the original BSD sources could contribute to local privilege escalation when combined with a separate kernel flaw. Calif says it demonstrated a path to root access despite several protections; OpenBSD addressed the issues in errata 026 and 018. The report also identifies allocator predictability and kernel data-structure protections as areas for further mitigation.
Security firm Calif has described a local privilege-escalation path in OpenBSD that combined a shared-memory counter bug traced to the original BSD sources with a separate kernel out-of-bounds write. Calif said the chain could yield root access even with KARL, SMAP and SMEP enabled; the firm says the two issues were addressed in OpenBSD errata 026 and 018.
The older flaw involved shm_nattch, a shared-memory attachment counter defined as a signed 16-bit short. Calif reported that repeated process forking could push the counter beyond its maximum positive value of 32,767, making it wrap to a negative number. That accounting error could contribute to a use-after-free through a race condition, according to the report.
Calif said it combined that condition with a separate out-of-bounds write in the kernel. Its exploit used shared-memory operations and process creation to trigger the counter wrap, then attempted to win a race while the kernel handled shared-memory attachments. The researchers described using a socket allocation and a linked-list removal operation to alter kernel memory and gain control of execution.
The company said the exploit reached kernel code execution and a root shell without relying on an information-disclosure vulnerability. It reported success with KARL, OpenBSD’s kernel relinking mechanism, and the hardware protections SMAP and SMEP enabled. These are findings from Calif’s research report; the supplied material does not include an independent reproduction or an OpenBSD statement describing the exploit.
How the Exploit Reached Root
The report matters because it shows how a small, old accounting bug can become more serious when paired with another memory-safety flaw and favorable kernel memory behavior. The counter overflow alone is not described as a complete route to root; Calif’s account depends on a race condition, an out-of-bounds write and the ability to target kernel structures.
Calif also argues that address randomization does not remove every predictable target. The report says KARL randomizes kernel function and data addresses, but the kernel allocators remain deterministic in relevant ways. According to the researchers, predictable allocation patterns made certain kernel pointers useful targets in their exploit. This points to a distinction between randomizing a kernel image and randomizing the locations and order of later allocations.
For OpenBSD users and developers, the reported fixes address the identified flaws, while the proposed mitigations could reduce the chance that similar memory corruption can be turned into control of the kernel. The report does not establish that the chain was used against systems in the wild.
As an affiliate, we earn on qualifying purchases.
From BSD Sources to OpenBSD Errata
Calif says the counter’s signed 16-bit definition dates back about 37 years, to the original BSD source code. The age of the code is a historical detail, not evidence that the flaw remained exploitable in every intervening BSD-derived system or release.
The report says OpenBSD addressed the problems through errata 026 and 018, assigning the shared-memory counter issue and the separate out-of-bounds-write issue to those notices, respectively. Calif frames its work as vulnerability reporting and remediation assistance, and says it provided suggested patches to OpenBSD earlier in the year. The provided source does not specify the affected release numbers or patch dates.
Calif also outlined possible defenses beyond the fixes: safe unlinking to check linked-list invariants before memory writes; randomizing the location of the recursive page-table mapping; and reducing allocator predictability through address or allocation-order randomization. It presents these as options, not as changes confirmed to have been adopted by OpenBSD.
“Big fish. Small counter. Root shell.”
— Calif, in its research report
kernel vulnerability testing software
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Scope and Exploit Conditions
The available report does not identify which OpenBSD releases were affected, when each erratum was issued, or whether the fixes were backported across supported versions. It also does not provide a separate technical response from OpenBSD or an independent verification of Calif’s exploit results.
The reported method requires local execution and several carefully coordinated kernel behaviors. The source does not say whether the vulnerability was exploited in real-world attacks, how many systems may have been exposed, or whether the additional mitigation ideas have been implemented. Calif’s detailed description is a researcher account, not evidence of active exploitation.
As an affiliate, we earn on qualifying purchases.
Patch Status and Further Mitigations
OpenBSD users should consult errata 026 and 018 and apply the relevant fixes for their release, following the project’s official instructions. The source material does not provide enough version information to specify which systems require which patch.
Further developments to watch for include OpenBSD’s response on the scope of affected releases and whether it adopts any of Calif’s proposed hardening measures, such as safe unlinking or additional randomization. Calif also raises compiler-based array-bounds checks as a possible way to catch some out-of-bounds accesses; the report does not say that OpenBSD has enabled such checks in production builds.
As an affiliate, we earn on qualifying purchases.
Key Questions
What was the old OpenBSD bug?
Calif traced it to a signed 16-bit shared-memory attachment counter. Repeated operations could make the counter exceed 32,767 and wrap to a negative value, contributing to a race-related use-after-free, according to the report.
Did the counter bug alone give an attacker root access?
Calif describes a chain involving the counter flaw, a separate out-of-bounds write, a race condition and predictable kernel memory behavior. The report does not describe the counter overflow alone as sufficient for root access.
What protections did Calif say were enabled?
The company said its exploit worked with KARL, SMAP and SMEP enabled, and without an information-disclosure vulnerability. That is Calif’s account of its testing.
Has OpenBSD fixed the reported issues?
Calif says the two issues were addressed in errata 026 and 018. The supplied material does not identify affected release versions or give patch instructions, so users should check OpenBSD’s official errata for their system.
Is there evidence the flaw was used in attacks?
The source material does not report in-the-wild exploitation. It describes Calif’s research and an exploit demonstration, but does not establish that attackers used the chain against deployed systems.
Source: hn
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
