Live data from Hacker News

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

nvd.nist.gov

11–20 of 170 posts

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

#12
post #4

Seems to be found as a part of Patch The Planet [0] which is basically OpenAI giving model access and Trail of Bits using them to find vulnerabilities in OSS projects. [0] https://openai.com/index/patch-the-planet/

neat, i'm a big fan of trail of bits but apparently missed this announcement. here's their post: https://blog.trailofbits.com/2026/06/22/introducing-patch-th... and a summary of week 1: https://gist.github.com/patch-the-planet/69fd1aa925c8e73edea...

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

#13
post #8

OpenBSD's security stance being the stuff of legend, I'm curious how many vulns have been found over the last couple months while the big model companies are flaunting their ability to find exploits. It'd be super cool to see it remain tiny.

According to https://openai.com/index/patch-the-planet/

Linux: 24 LPEs, plus many additional vulnerabilities.

OpenBSD: 1 LPE.

FreeBSD: 7 LPEs, plus many additional vulnerabilities.

Not sure what that says, though. Perhaps the models are more likely to find Linux issues because of the training.

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

#14
Would Rust have made this issue impossible by construction? I know Linus has spoken about Rust's promises about memory safety not being equivalently applicable in the kernel domain, so I would be curious to hear any kernel developer's perspectives.

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

#16
post #9

If this is a local privilege escalation to root, why can't I find anything on https://www.openbsd.org/security.html ?

Best guess, from the commit message alone[0]: It was fixed as a bug, at the time they didn't have evidence it could lead to LPE

The AI security tool then, retroactively discovered that it could have been used for LPE.

Again, just my guess I could be wrong.

[0] https://github.com/openbsd/src/commit/1957873d2063db11dab780...

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

#17
post #14

Would Rust have made this issue impossible by construction? I know Linus has spoken about Rust's promises about memory safety not being equivalently applicable in the kernel domain, so I would be curious to hear any kernel developer's perspectives.

The Rust ownership model prevents use after free. This type of a bug would not compile.

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

#18
post #9

If this is a local privilege escalation to root, why can't I find anything on https://www.openbsd.org/security.html ?

OpenBSD has a reputation for being... selective about what they admit is a security-relevant bug.

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

#19
post #15

[flagged]

The OpenBSD project was started in 1995, with ancestry going back further than that. Should they have first invented Rust? Or at what point do you suppose the decades-old codebase should have been completely rewritten?

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

#20
post #14

Would Rust have made this issue impossible by construction? I know Linus has spoken about Rust's promises about memory safety not being equivalently applicable in the kernel domain, so I would be curious to hear any kernel developer's perspectives.

Rust is designed to make this type of issue impossible, but that assumes that you can correctly encode object lifetimes in the kernel in a way that allows the compiler to check them.

So I would say that any easy answer like “this would not compile” would just be a guess, because you would want to know more of the particulars in order to answer this question.

I know that this is kind of a non-answer, but if you want to write a kernel in Rust you have to figure out boundaries for where unsafe {} are. In a kernel, there are probably large chunks of unsafe {} and the Rust compiler prevents certain bugs outside unsafe {} assuming there aren’t bugs inside unsafe {} that would prevent the type checker from doing its job correctly.

Post reply on HN