That's a good catch. Yes, since they've only proven this up to the jailer boundary, you'd need a second and relatively powerful LPE vulnerability to get real host control out of this.

▲

rvz 2 days ago | parent [-]

Thanks to frontier reasoning agents, Linux is completely riddled in ways you can discover 900+ LPE vulnerabilities. [0]

Another wave of vulnerabilities like this are yet to be discovered in Linux. We are just seeing how weak C and C++ based OSes and kernels are when put under hundreds of AI agents.

[0] https://openai.com/index/a-thousand-fewer-paths-to-root/

▲

devmor 2 days ago | parent | next [-]

We always knew this, it has been understood since nearly the dawn of the monokernel OS that there is always a route to privilege escalation somewhere. This is why even for web applications that would be better served by a shell, people choose CGI-style interfaces instead.

The only reason it wasn't seen as a problem was due to the effort and time it took to find and exploit them.

▲

imnotsuretheykn 2 days ago | parent | prev | next [-]

Watch Hartman’s response to the first wave of issues found by AI. Super dismissive and ignorant.

I’m not sure the people that caused this will be the one fixing it.

	▲	fock 2 days ago \| parent [-]
		you sure the people who caused this (speeding up Linux to mainly serve ads instead of hardening it?) aren't the exact same people now pushing the antidote?

▲

rockskon 2 days ago | parent | prev [-]

And how many of these vulns are in code for legacy hardware or filesystem support that in no way reflects threats against modern Linux installs? I wager the overwhelming majority of them.

▲

wahern 2 days ago | parent | next [-]

The recent OpenAI release linked above targeted only ~3M SLoC (out of ~40M), core systems code reachable from within a simple VM guest.

▲

codedokode a day ago | parent | prev [-]

And are those legacy filesystems disabled by default and require root to invoke the code?

▲

jasomill a day ago | parent [-]

On a VM host, only root will be able to mount filesystems or make block-level writes to already-mounted filesystems. So LPE via a filesystem you'd need an exploit that can be triggered by writing to an already mounted filesystem with filesystem operations only as a non-root user.

As I understand it, even commonly-used filesystems aren't considered hardened against arbitrary malicious data, the party line is to use userspace filesystems to mount untrusted volumes.

	▲	codedokode 14 hours ago \| parent [-]
		What about namespaces, if a user creates a user namespace and becomes root inside it?