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

Original Article ↗ Hacker News Discussion ↗

A newly disclosed use-after-free bug in OpenBSD’s SysV semaphore code allows local users to escalate privileges to root, challenging the project’s reputation for near-flawless security. Commenters note that the flaw was found by an AI-assisted audit (OpenAI and Trail of Bits’ “Patch the Planet”), compare the single OpenBSD local privilege escalation to more numerous issues found in Linux and FreeBSD, and debate how codebase size, development practices, and minimal default configurations affect real-world security. There is also extensive debate over whether Rust or other memory-safe approaches could have prevented this class of bug, and how cost-effective AI-driven vulnerability hunting really is.

Vulnerability & impact

  • CVE describes a use-after-free in sys/kern/sysv_sem.c (SysV semaphores) in OpenBSD ≤7.9 enabling local privilege escalation (LPE) to root.
  • It’s a context-switch UAF after tsleep in sys_semget().
  • Commenters stress it’s serious but not a “remote hole.”
  • Accessibility from sandboxed processes is discussed; a linked pledge(2) implementation suggests sandboxed base daemons generally can’t use these syscalls.

Discovery and AI-assisted auditing

  • Bug appears to have been uncovered in the “Patch The Planet” initiative (OpenAI models + Trail of Bits) scanning open-source projects.
  • Some infer it was first fixed as a generic bug; only later was its LPE potential recognized, possibly by the AI tooling. This is labeled as a guess, not confirmed.
  • Patch The Planet’s own stats: Linux 24 LPEs, FreeBSD 7, OpenBSD 1, plus many non-LPE issues.
  • Debate over whether AI-based audits are cost-effective versus funding traditional security research.

OpenBSD security record & “marketing”

  • OpenBSD’s “only two remote holes in the default install” slogan is both praised as technically accurate and criticized as selective:
    • Default install is minimal and has most services disabled, so real-world systems differ.
    • Still, minimal defaults and aggressive hardening (pledge, unveil, W^X, ASLR, etc.) are seen as genuine strengths.
  • Some argue OpenBSD sometimes downplays or filters what it labels as “security bugs,” partly because many reported issues are overhyped or impractical.

Comparisons with Linux/FreeBSD and code size

  • Multiple commenters link more bugs in Linux/FreeBSD to:
    • Larger codebases and more features/drivers.
    • Higher development churn.
  • Lines-of-code comparisons are cited; fewer LOC is associated with fewer bugs, though the exact security implications are debated.

Local privilege escalation relevance

  • One view: LPEs matter less for typical OpenBSD server deployments that don’t run untrusted code.
  • Counterargument: LPEs become critical when chained with RCE or supply-chain attacks; they’re key in defense-in-depth.

Rust and memory safety discussion

  • Many note Rust’s ownership model is designed to prevent UAF, so a straightforward version of this bug likely wouldn’t compile.
  • Others emphasize kernel reality:
    • Large portions must be unsafe, especially around interrupts, DMA, and low-level primitives.
    • The safety of “safe” Rust depends on correctness of underlying unsafe code.
  • Consensus: Rust significantly reduces certain bug classes but doesn’t magically eliminate kernel vulnerabilities.

OpenBSD design trade-offs and features

  • Several argue OpenBSD’s good showing (one LPE) reflects culture, careful engineering, and a deliberate feature set.
  • There’s debate whether OpenBSD is truly “minimal”:
    • Some say it omits major subsystems (e.g., Bluetooth, “modern” filesystems like ZFS) partly for security and maintenance reasons.
    • Others note the base system is actually rich (e.g., BGP daemons, networking tools), just with a different philosophy and scope.
  • Lack of journaling/ZFS for routers is questioned; defenders point to fully synchronous FFS and ask what router data truly must survive power loss.

DNS tooling and OpenWRT tangent

  • Separate thread branch criticizes dnsmasq’s recent vulnerability history; some have removed it from their systems.
  • OpenWRT’s default use of dnsmasq is questioned; alternatives like Unbound (with or without NSD) are suggested, but dnsmasq’s “all-in-one” DNS/DHCP/BOOTP/TFTP role makes replacement nontrivial.