Qemu escape?! | TheaterFire

[-]

yawn_brendan@reddit

We look at every kernel CVE and kCTF exploit in my team at work. The last couple of weeks have actually been pretty normal (very high volume to be sure but not unprecedented).

Copy.fail, DirtyFrag, the ptrace one from today... These are not very interesting, bugs like this are very common the only unusual thing was the attention they got.

A QEMU escape exploit using CXL though, that's where things start to get interesting! And I think it will continue from here. This is certainly not unheard of but issues like this were much harder to come by historically and much higher impact.

(CXL is kinda fresh and likely to have bugs, also only used in quite specific environments. But I still think we are gonna see this accelerate, there are plenty of bugs to be found with this type of exploitability)

[-]

CrazyKilla15@reddit

bugs like this are very common

..thats worse?

[-]

yawn_brendan@reddit

Yes, it is very bad. We have been trying to get this message out for years and for some reason it hasn't worked.

Now finally people are noticing the situation but everyone seems to think it's a new situation.

[-]

shroddy@reddit

Tried to suggest that maybe the Linux kernel has a hard time providing a proper security boundary and needs extensive hardening, sitting on 60 downvotes so far. https://www.reddit.com/r/linux/comments/1tc3q12/comment/ollg39e/

[-]

Jmc_da_boss@reddit

Full universal LPEs like dirty frag are not normal at all?

[-]

yawn_brendan@reddit

They are very normal

[-]

Worldly_Topic@reddit

This is why people say containers are not an effective security boundary.

Unprivileged containers with user namespaces are effective though.

[-]

yawn_brendan@reddit

No they are not, this is literally the point. Any of the recent LPEs will escape from one of those.

[-]

Worldly_Topic@reddit

No they won't. You would only get root within the namespace of the container, not real root on the host OS. Uid 0 within the container will be mapped to some random unprivileged user on the host.

[-]

yawn_brendan@reddit

You are wrong. Read the copy.fail website for some examples.

[-]

Worldly_Topic@reddit

Read this for how rootless podman containers limit copy.fail exploit

[-]

yawn_brendan@reddit

This seems to just be demonstrating the the exploit as written didn't work in their environment. In the website they show how they can overwrite bytes in the page cache which proves it can be used to gain global root.

[-]

Worldly_Topic@reddit

In the website they show how they can overwrite bytes in the page cache which proves it can be used to gain global root.

Only if you mount some setuid binary into the container. If the container is fully isolated then the exploit can't be used to overwrite bytes of files from host.

[-]

CrazyKilla15@reddit

Correct. It is worth noting though that it can enable cross container exploitation, since containers with a common base layer(where many setuid binaries will live) will share the same backing file, and thus page cache.

[-]

Worldly_Topic@reddit

You can still use the no new privileges flag of podman to prevent setuid binaries from working inside the container.

[-]

CrazyKilla15@reddit

That seems likely to break whatevers being run in containers themselves, no?

[-]

Worldly_Topic@reddit

There are some images that are labelled as rootless which should work without issues.

For other images, your mileage may vary.

[-]

Megame50@reddit

The only thing that's changed really is each discovery now has a slick name and website generated by AI. It's very common for multiple similar vulns to be discovered back to back.

[-]

yawn_brendan@reddit

Each discovery does not have a slick name, only 3 in or 4 have got slick names. They are not the only LPEs of the last few weeks.

[-]

mocket_ponsters@reddit

Copy.fail, DirtyFrag, the ptrace one from today... These are not very interesting, bugs like this are very common the only unusual thing was the attention they got.

Now hold on, I don't work in cybersec professionally and I'm sure you might have a lot more evidence to support your point, but doesn't this seem a bit dismissive? Most CVEs I've seen in the kernel that give full root-privileges typically use obscure netfilter configurations, unreliable race conditions, or bugs in subsystems that require unusual hardware or already elevated privileges to exploit anyways.

The distance between having 'vulnerability exists' and 'vulnerability is practically exploitable' is usually significantly larger in the hundreds of CVEs that get published each year. Not to mention that it was essentially ubiquitous across every single modern distribution released.

In contrast, this bug might have more interesting technical details, but it requires CXL emulation which I am struggling to imagine having any sort of use case in any production system. At best it's a sign that CXL codebase has not been hardened yet, but in my opinion it's this particular bug getting attention that's 'unusual'. If it was exploitable on say, a VFIO passthrough of a CXL device (can that be done in QEMU yet?), then it would be far more concerning.

[-]

yawn_brendan@reddit

https://github.com/google/security-research/tree/master/pocs/linux/kernelctf

All those obscure netflilter configurations are exploitable on most distros.

Although you are correct that an insane amount of bugs come from random netlink garbage like that, which does mean you can make a huge dent in the volume of you can fix that (which, again, most distros haven't). But this doesn't change the order of magnitude of the vulns.

"Unreliable race conditions" -> doesn't matter attackers have a toolkit for making them reliable. Just coz some vulns are easier to exploit than others doesn't mean you can dismiss the latter as a threat, they are there on your system.

You are right that the need for CXL makes this much less concerning but the fact that it is demonstrated against virtualized attack surface more than balances that out.

[-]

AmarildoJr@reddit

2026 will be the year of the exploits, where it rains exploits on everybody 😃

[-]

marmarama@reddit

ITYM: 2026 will be the year of the lame LLM-discovered half-exploit that someone cosplaying as a security researcher attempts to pass off as a major issue for internet points.

[-]

shroddy@reddit

That was 2025, unfortunately in 2026 these LLMs are capable of finding actual exploits.

[-]

TheOgGhadTurner@reddit

Yeah. I’m still convinced Microsoft is somehow funding this entire thing in an attempt to make Linux seem completely insecure and attempt to curb people from leaving

[-]

Flash_Kat25@reddit

"This whole thing" as in security research on Linux? I get where you're coming from but that's kind of a crazy conspiracy theory

[-]

Jmc_da_boss@reddit

That was last year, these latest ones are very real, I ran dirtyfrag on a fresh Debian install and it rooted it instantly

[-]

yawn_brendan@reddit

And 2023, and 2024, and 2025: https://github.com/google/security-research/tree/master/pocs/linux/kernelctf

(I think there are older ones too?)

This is just the year that, for some reason, people started paying attention.

[-]

CryoRenegade@reddit

Heres the xcancel link for those who dont use twitter https://xcancel.com/v12sec/status/2055282721212252178

[-]

linuxjohn1982@reddit

Very appreciated :)

[-]

Sol33t303@reddit

Nah that time when windows went into a permanent boot loop and everybody had to spend weeks manually resetting each devices was far crazier.

[-]

grathontolarsdatarod@reddit

This would never be able to compromise a digital id or age verification setup, right?

[-]

deviled-tux@reddit

No, this has nothing to do with that.

[-]

grathontolarsdatarod@reddit

Would this system be used I'm facilitating the servers?

Would those servers use VMS?

[-]

surreal3561@reddit

It doesn’t matter what they use, it’s completely unrelated.

ID or Age verification is done by submitting data to the server.

This is an exploit that requires you being able to access the server itself and run code on it (oversimplifying).

It’s like sending a letter to someone in prison vs an actual inmate escaping prison.

[-]