OpenBSD kernel race gives local users a root shell

OpenBSD sells itself on being the paranoid Unix, the one whose default install has famously survived years without a remote hole. That reputation was always about defaults and remote attack surface, never a promise that the kernel was free of local bugs. CVE-2026-57589 is a reminder of the difference. It's a use-after-free in sys/kern/sysv_sem.c that lets an unprivileged local user escalate to root on every OpenBSD release up to and including 7.9. The interesting part isn't the severity. It's how ordinary this class of bug is, and the odd footnote attached to how it was found.

The NVD entry describes it precisely: "a context switch use-after-free after tsleep in sys_semget()." MITRE, acting as CNA, assigned a CVSS 3.1 base score of 7.4 (HIGH) with the vector AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Read that vector carefully, because it tells you almost everything about how worried to be.

Anatomy of a sleep-and-use race

SysV semaphores are the old System V IPC primitive, still present in OpenBSD and used by anything that reaches for semget(2), semop(2) and friends. The semget() syscall path allocates or looks up a semaphore set. Somewhere in that path the kernel calls tsleep(), the classic BSD routine that voluntarily blocks the current thread until a wakeup event fires.

That sleep is the whole vulnerability. When a thread sleeps, the scheduler is free to run something else on the same data structures. If the code grabbed a pointer to a semaphore object before the tsleep() and kept using it after waking, a second thread can free or reallocate that object during the sleep window. The first thread wakes up holding a dangling pointer and operates on freed kernel memory. That's CWE-416, use-after-free, and in kernel context it's a well-trodden road to controlled memory corruption and, from there, root.

sequenceDiagram
    participant A as Thread A (attacker)
    participant K as Kernel semget path
    participant B as Thread B (racer)
    A->>K: semget() grabs sem object ptr
    K->>K: tsleep() blocks, yields CPU
    B->>K: frees / reallocs the sem object
    K-->>A: wakeup, ptr now dangling
    A->>K: use-after-free -> corruption -> root

The reason attack complexity is rated High is that you have to win this race, and races after tsleep are timing-dependent. You don't get a deterministic one-shot exploit; you get a loop that hammers the syscall and occasionally lands. PR:N (no privileges required) here just means the attacker needs nothing beyond the ability to run code as a normal user, which is exactly the shared-host threat model this matters for. CISA's SSVC assessment currently marks exploitation as "none" observed and "automatable: no," but technical impact as "total." In plain terms: nobody's seen it fired in the wild, it's not a spray-and-pray, but if it lands you own the box.

The fix is a single commit to the OpenBSD source tree. Kernel UAFs of this shape are usually closed one of two ways: re-validate or re-lookup the object after the sleep instead of trusting the stale pointer, or hold a reference across the sleep so it can't be freed. Either way the lesson for anyone writing kernel or driver code is the same one that's been true since the 4.4BSD days. Any pointer you hold across a blocking call is suspect. The world can change while you sleep.

Not OpenBSD's first local root, and it won't be the last

The "secure by default" narrative has always coexisted with a steady trickle of local privilege escalation in OpenBSD. In late 2019 Qualys published a cluster that became something of a greatest-hits reel: an authentication bypass and multiple LPEs covering su -L login-class confusion (CVE-2019-19519), the xlock LIBGL_DRIVERS_PATH trick to reach the auth group (CVE-2019-19520), the login_style username-as-option bypass (CVE-2019-19521), and an S/Key and YubiKey path to root for auth-group members (CVE-2019-19522). Weeks later came the dynamic-loader bug (CVE-2019-19726), where a tiny RLIMIT_DATA made ld.so fail to strip LD_LIBRARY_PATH from setuid chpass or passwd, and working exploits for all of these are still sitting in public repos.

What separates CVE-2026-57589 from that lineage is where it lives. The 2019 bugs were mostly in userland setuid glue and authentication logic, the messy edges around the kernel. This one is in the kernel proper, in decades-old SysV IPC code that has presumably been read many times. Old, boring, low-glamour syscall paths are exactly where these things hide, precisely because everyone assumes they were audited to death years ago.

The provenance footnote worth watching

Here's the detail that got the community talking. Alongside the fix commit, the CVE record lists a second reference: an OpenAI page titled "Patch the Planet." Read the tea leaves and the implication is that this UAF surfaced through AI-assisted vulnerability research rather than a human auditor grinding through sysv_sem.c.

Treat that as unconfirmed context, not established fact. The reference is there, but the CVE metadata alone doesn't prove the discovery method, and it's worth being skeptical of any "the AI found it" framing that arrives without the actual methodology. Still, if it holds up it's a meaningful data point. A race-condition UAF in one of the most scrutinized open-source kernels on the planet is not the kind of finding that shows up in a weekend of grep. As one commenter on Lobsters noted, the more interesting question is whether this pace of machine-assisted bug discovery survives once inference stops being subsidized. If it does, the model auditors have long relied on, that obscure old code is safe because nobody bothers to look, is in trouble.

What operators should actually do

The honest priority read: patch on your normal cadence, and jump the queue only if you run multi-user OpenBSD.

• Shared shell servers, build farms, university boxes, any host where untrusted users run code are the real targets. AV:L means an attacker needs local execution, so anywhere that hands out local accounts is exposed. Prioritize these.
• Single-admin firewalls, routers and appliances where nobody untrusted has a shell are much lower risk. There's no remote vector here. Patch, but don't panic.
• Watch the errata and syspatch. At the time the CVE landed there was no syspatch on the errata page yet, so check OpenBSD's errata before assuming you're covered. If you build from source and can't wait, the upstream commit is the authoritative fix to cherry-pick and rebuild your kernel against.
• Don't count on a clean mitigation short of the patch. SysV semaphores are on by default and there's no tidy switch to make this go away without the code fix. Reducing who can get a local shell is the only real interim control.

The race complexity buys you a little time, not immunity. A hard-to-win race is still a race, and public PoCs for OpenBSD LPEs have a long history of turning "theoretically exploitable" into a copy-paste script. Apply the fix, and if the AI-discovery angle is real, get used to more findings like this in code you'd stopped worrying about.