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

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.