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/

Hang on, what are you getting at?

Wait, this is also presumably true, come to think of it. I'm a little fuzzy because they document the memory disclosure primitive carefully but not the memory writes they also got from it --- but whatever those are, they're hitting kernel memory? But the exploit they're describing here gets code execution out of Firecracker itself, not the kernel.

Just for what it's worth, that escape is much more situational than PwnEscape (there have been other escapes that depended on nested KVM, as well). Pretty much everyone seems to have been exposed with PwnEscape, because everyone using Firecracker is also using virtio-net.

Xen had a generic guest to host vulnerability disclosed in the last few days: https://codeant.ai/security-research/xenbleed-a-grant-copy-c...

This is a much lighter weight (~100k) alternative to Xen focused on baremetal TPM anchored remote attestation, formal verification, and trusted computing applications.

Anyone considering Xen should probably also consider Nova depending on requirements.

Xen is formally verified?

Nova is L4 inspired, and interchangable with L4 kernels in Genode.

The actual main open source repo has had that warning there for 14 years in spite of commercial forks that are deployed in production government and high risk use cases.

See his latest talk which represents a lot of impressive recent work: https://cfp.3mdeb.com/media/bsmconf/submissions/KW3SYT/resou...

I am working on a production OS using it as a foundation.

The actual vulnerability got very little discussion. It's clever. Because Linux networking people are obsessed with checksum performance, virtio-net plumbs checksum offload metadata through the host/guest driver interface. Guests can thus deliver the host packets along with instructions on what to checksum. The vulnerability is a missing sanity check that allows checksum instructions to instruct the host to overwrite the header length field in the IPv4 header, rather than the checksum field.

Crucially, this happens in the middle of packet processing, so the kernel code is forced to work with two different ideas of how long the IPv4 header is. All hell predictably breaks loose.

Fixed a month ago upstream

https://github.com/torvalds/linux/commit/6785011f8b16abf40b1...

https://www.pwn.ai/blog/pwnescape

Ah maybe not on HN, I forget where I learned of it. Either way, multiple weeks ago: https://news.ycombinator.com/item?id=50108845

I seem to remember there's a system in place to prevent duplicates (where the submission of a duplicate link results in the upvote of the original story), but maybe that's limited to the first 24h? Idk, HN works in mysterious ways

This has negative impact on searching older discussions. Instead of 1 result for 1 URL (within few month) getting 2 or even more.

I would've thought that you could actually have an incredibly strict seccomp policy for the jailer which would require you to find an LPE in something like open(2), which seems unlikely even in the "agent swarm" era.

That's not the default gvisor option. It can use kvm, but by default (and most common setup in my limited experience) it doesn't.

(A more complete way to say this is that Firecracker is the engine built to run AWS Lambda and AWS Fargate).

It has notable adoption in the agent sandbox space where this type of vulnerability is especially volatile.

> The target was Firecracker v1.16.1 on x86-64, with host kernel 7.0.0-1011-aws.

Fly uses it too afaik

Informative LLM slop is still LLM slop. We need to insist on high standards of content readability as well as substance. Peer pressure and negative reviews are one way we can influence others.