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
tsleepinsys_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
unsafecode.
- Large portions must be
- 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.