HN Debrief

OpenBSD has a use-after-free allowing local privilege escalation to root

  • Security
  • Open Source
  • Infrastructure
  • AI

The submission points to CVE-2026-57589, a kernel use-after-free in OpenBSD’s SysV semaphore code that affected releases through 7.9 and could be turned into a local privilege escalation to root. Several commenters tied the finding to Patch the Planet, a program where OpenAI models and Trail of Bits are used to hunt for bugs in open source software. That framing set the tone. People did not treat this as proof that OpenBSD is suddenly insecure. They treated it as a useful stress test for a codebase that has spent decades optimizing for simplicity, compartmentalization, and conservative engineering.

Treat this as evidence that AI-assisted review is now good enough to surface exploitable bugs even in security-first codebases, not as evidence that OpenBSD’s model failed. If you run infrastructure software, the practical move is to combine smaller attack surface, compartmentalization, and aggressive auditing rather than betting on any one language or brand of operating system.

Discussion mood

Mostly respectful and mildly impressed. Commenters saw the bug as real and important, but also as a sign that OpenBSD’s security-focused design and limited attack surface held up unusually well under AI-assisted auditing. The main skepticism was aimed at overinterpreting the result, either as proof OpenBSD is uniquely secure or as proof AI bug hunting is already an efficient replacement for human security work.

Key insights

  1. 01

    pledge likely blocked many paths

    The SysV semaphore path at issue does not appear to be available to pledged processes, which changes how dangerous this bug is in practice. That matters because most network-facing daemons in the OpenBSD base system reportedly run under pledge, so a future remote bug would have a harder time chaining into this specific local root path.

    Do not score kernel bugs by CVSS alone. Check whether your sandbox model actually removes the vulnerable syscall or capability from exposed services, because that often decides whether a bug is chainable.

      Attribution:
    • brynet #1
  2. 02

    The CVE may postdate the fix

    The absence of an advisory on OpenBSD’s security page likely means this landed first as a plain bug fix and was only later recognized as a privilege escalation. That reinforces a long-running OpenBSD habit of being narrow about what it labels security-relevant, which can keep the public record cleaner but also makes headline counts an imperfect measure of risk.

    When you track upstream security posture, follow commit history and bug-fix patterns, not just formal advisories. A project’s disclosure taxonomy can hide how often dangerous bugs are fixed quietly.

      Attribution:
    • justthehuman #1
    • stackghost #1
  3. 03

    Rust helps most outside unsafe islands

    Rust would probably reject the straightforward version of a use-after-free like this, often by forcing a reference-counted design or an explicit unsafe escape hatch. But kernel work is full of interrupts, DMA, shared global state, and lifetime relationships the compiler cannot infer cleanly. That means the win is not “no kernel memory bugs.” The win is shrinking the amount of code reviewers must treat as dangerous and making the danger obvious.

    If you are evaluating Rust for systems code, measure how much risky code you can isolate behind tiny reviewed unsafe modules. That is a much better predictor of security payoff than asking whether Rust can eliminate every kernel bug class.

      Attribution:
    • kevincox #1 #2
    • MindSpunk #1
    • ryukoposting #1
  4. 04

    OpenBSD router setups avoid filesystem drama

    The complaint that OpenBSD lacks a modern journaled or checksumming filesystem did not really dent its router use case. People running it as network gear described diskless or read-mostly deployments, remote logging, and fully synchronous FFS mounts as enough to make sudden power loss a non-event for the appliance role OpenBSD is often chosen for.

    Match your storage expectations to the appliance role. If you only need a firewall or router, design the box so persistent writes are rare and disposable instead of demanding a storage-heavy stack from the OS.

      Attribution:
    • pianopatrick #1 #2
    • spauldo #1
  5. 05

    AI auditing may still be subsidy priced

    Several commenters accepted that model-assisted tools are finding bugs, then argued that the economics are still distorted. If the true cost includes training runs, GPUs, and deficit-funded infrastructure, this is not yet obviously cheaper than paying strong human researchers. The current wave makes more sense as strategic customer acquisition for AI vendors than as settled proof of a better security business model.

    Use the results, but do not build your security budget on today’s AI pricing assumptions. Expect tooling access and economics to change once the subsidy phase ends.

      Attribution:
    • cratermoon #1
    • dTal #1

Against the grain

  1. 01

    Low attention could explain low bug counts

    A skeptical take was that OpenBSD may look cleaner partly because it gets less adoption and less scrutiny than bigger targets. That does not square neatly with this audit finding only one OpenBSD local root issue, but it is a useful warning against treating public vulnerability counts as a complete map of security quality.

    If you compare platforms, normalize for who is looking and why. Bug counts without attacker incentives and audit intensity can mislead procurement and architecture decisions.

      Attribution:
    • rs_rs_rs_rs_rs #1
  2. 02

    The default install slogan overstates safety

    The famous OpenBSD line about remote holes in the default install was called out as technically true but carefully scoped. A machine in its default state does very little, so the slogan says less about the security of real deployed systems with packages, services, and custom configuration than fans sometimes imply.

    When vendors or projects cite security records, check the boundary conditions. Ask whether the claim still holds once the system is configured for your actual workload.

      Attribution:
    • JCattheATM #1
    • tredre3 #1
    • stackghost #1
  3. 03

    Security comes partly from leaving features out

    Some commenters argued that OpenBSD’s good security story is inseparable from the fact that it simply declines to implement or prioritize a lot of functionality, from Bluetooth to broader hardware and storage support. That makes the system easier to reason about, but it also narrows where it is competitive and can turn missing features into hard adoption limits.

    Be honest about whether reduced attack surface is coming from better engineering, a smaller feature set, or both. That distinction matters when you choose a platform for product requirements that may grow over time.

      Attribution:
    • tiffanyh #1
    • knorker #1 #2

In plain english

attack surface ↩
The total set of code paths, features, interfaces, and services that could potentially be exploited.
checksumming filesystem ↩
A filesystem that stores integrity checks for data so corruption can be detected, and sometimes corrected.
CVE ↩
Common Vulnerabilities and Exposures, a public identifier for a specific disclosed security flaw.
DMA ↩
Direct Memory Access, a hardware feature that lets devices read or write memory without the CPU handling each byte directly.
feature churn ↩
Ongoing code changes from adding, modifying, or expanding features, which often increases complexity and bug risk.
FFS ↩
Fast File System, the traditional BSD filesystem family used by OpenBSD.
local privilege escalation ↩
A flaw that lets someone with limited access on a machine gain higher privileges, such as administrator or root.
Patch the Planet ↩
A program mentioned in the comments that uses OpenAI models together with Trail of Bits to find vulnerabilities in open source software.
pledge ↩
An OpenBSD security feature that lets a program declare which classes of system calls it will use, so the kernel can block the rest.
remote code execution ↩
A vulnerability that lets an attacker run code on a target system from afar, often over a network.
root ↩
The all-powerful administrative user account on Unix-like systems.
Rust ↩
A programming language designed to prevent many memory safety bugs through compile-time ownership and borrowing checks.
syscall ↩
A system call, which is the interface a program uses to request services from the operating system kernel.
Trail of Bits ↩
A security research and consulting firm known for software audits and vulnerability research.
unsafe ↩
A Rust language feature that allows operations the compiler cannot fully verify as safe, placing more responsibility on the programmer.
use-after-free ↩
A memory safety bug where code keeps using an object after it has already been released, which can lead to crashes or arbitrary code execution.

Reference links

AI-assisted security programs

OpenBSD source and documentation

  • OpenBSD fix commit
    Used to support the idea that the issue may have first been fixed as a bug before being recognized as a security issue.
  • pledge syscall policy source
    Referenced to show that the vulnerable semaphore functionality was not reachable from pledged processes.
  • OpenBSD config manual
    Shared to explain how OpenBSD statically and at runtime controls compiled-in drivers and kernel configuration.
  • OpenBSD mount manual
    Linked for the sync mount option discussed as a way to make FFS more robust on appliance-style systems.

Papers and research

Filesystem and operations references

Code examples

  • GNU coreutils yes.c
    Posted as an example of a more optimized and more complex implementation than OpenBSD’s minimalist equivalent.
  • OpenBSD yes.c
    Shared to illustrate OpenBSD’s preference for simpler implementations.
  • FreeBSD yes.c
    Added as a middle ground example, with Capsicum sandboxing noted in the comment.

Background references