Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

github.com

Post reply on HN
Print view View original

51–60 of 67 posts

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#51

Post by marysol5 »

TZubiri wrote: post #7

hey, here's a good rule of thumb. If you share resources, that reduces costs, but increases security risks. choose whether to share a filesystem, an OS, a kernel, hardware, or just use a dedicated server. The economics of sharing resources are all in a tiny sliver of the budget spectrum, the shoestring budget range : 0-1$/mo: serverless 1$-5$/mo containers 5$-200$/mo Virtual Machine(s) 200$-1Billion$/month , at least…

In your context you still "share" with a dedicated server too. It's not your rack, it's not your IPMI/OOB, even on bare metal. Components in the server are running all sorts of their own code.

All of these layers are a form of risk

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#52

Post by marysol5 »

codedokode wrote: post #16
antonvs wrote: post #9

Earlier quoted context omitted.

If you can run everything you need on two or three servers, what you describe can work. But it’s still hobby status, basically. The equation changes when the scale gets significantly bigger. Managing a non-trivial hardware fleet requires people, and people cost money. The reason “managed services” of all kinds, including cloud services, are so widespread in business is because someone else is managing things so that…

One server is enough for many small businesses. And for large business (like X or Instagram) it is economically more profitable to own their servers. For example, in my country top companies like VK or Yandex own their datacenters and sell cloud services instead of paying for someone's else cloud. Also if you have several servers you do not need to hire a full-time sysadmin. > Managing a non-trivial hardware fleet re…

>own their datacenters and sell cloud services instead of paying for someone's else cloud.

Or because it's cost-effective to slice up your infrastructure and sell off the bits you're not using right now.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#53

Post by tryauuum »

bonzini wrote: post #36
rvz wrote: post #4

The full write up is here: [0]. This is a very nasty vulnerability and risks any service that uses and allows nested x86 virtualization features at risk. Including those running VMs as a service. > Running the PoC inside a guest VM can trigger a host kernel panic. A full escape exploit that works in a controlled environment also exists, but it is not released at this time and is planned to be released in the very dis…

KVM maintainer here. For what it's worth, this is a variant of a vulnerability discovered via fuzzing last April, CVE-2026-46113.

how dangerous is the vulnerability in practice? How hard is to actually achieve the KVM escape?

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#54

Post by nijave »

TZubiri wrote: post #7

hey, here's a good rule of thumb. If you share resources, that reduces costs, but increases security risks. choose whether to share a filesystem, an OS, a kernel, hardware, or just use a dedicated server. The economics of sharing resources are all in a tiny sliver of the budget spectrum, the shoestring budget range : 0-1$/mo: serverless 1$-5$/mo containers 5$-200$/mo Virtual Machine(s) 200$-1Billion$/month , at least…

I'm a bit confused. So you're saying instead of running 20 containers for an app that are 1-4Gi and some odd CPU I should replace them with 20 dedicated servers?

By your own numbers that's 200x+ as expensive.

Really 20 containers is a pretty small app considering 5 app server containers, a DB, a cache, a load balancer, some monitoring/alerting crap 2x for redundancy.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#55

Post by fulafel »

codedokode wrote: post #42
fulafel wrote: post #35

Earlier quoted context omitted.

Linux controls access using configurable file permissions, so this has a false premise. The better question is doesn't RHEL really use a kvm group to limit access like other distributions? If so, why?

The permissions are per-user, not per-app and that is the problem. The distibution developers assume that you trust the programs you run, but how can I trust commercial and proprietary software? How can I trust the code from a random guy on Github without a passport verification?

Depends on your setup, you can have per-app permissions too. Flatpak, snap etc do this for desktop apps, Android does it, containerized server apps do it. But of course if it turns out you're running malware, you're going to have problems when it transpires that you've delegated something valuable to it, even if it doesn't break out of its permission set.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#56

Post by fulafel »

rwmj wrote: post #46
fulafel wrote: post #35

Earlier quoted context omitted.

Linux controls access using configurable file permissions, so this has a false premise. The better question is doesn't RHEL really use a kvm group to limit access like other distributions? If so, why?

Because you want users to use virtualization for sandboxing without needing to make system-wide changes. That generally improves security overall. You might as well ask "why allow users to run anything at all?" since they can make system calls into a gigantic C program that is likely full of unknown bugs.

I get where you're coming from but I'd argue the kvm group is still better even when you automatically give all human users membership. You can then have less-privileged accounts for service roles, for example nginx doesn't need kvm acccess.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#57

Post by nijave »

codedokode wrote: post #16
antonvs wrote: post #9

Earlier quoted context omitted.

If you can run everything you need on two or three servers, what you describe can work. But it’s still hobby status, basically. The equation changes when the scale gets significantly bigger. Managing a non-trivial hardware fleet requires people, and people cost money. The reason “managed services” of all kinds, including cloud services, are so widespread in business is because someone else is managing things so that…

One server is enough for many small businesses. And for large business (like X or Instagram) it is economically more profitable to own their servers. For example, in my country top companies like VK or Yandex own their datacenters and sell cloud services instead of paying for someone's else cloud. Also if you have several servers you do not need to hire a full-time sysadmin. > Managing a non-trivial hardware fleet re…

No it's not. The poster is advocating replacing technology to share a single system with dedicated, non-shared systems.

Even the most basic business app has an app server and a database server. If they have 6 business apps, they'd have at least 7 dedicated servers (assuming we're allowing a database server to have multiple app databases sharing it)

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#58

Post by nijave »

bonzini wrote: post #50
nijave wrote: post #48

Earlier quoted context omitted.

IBM mainframes might but I have a very shallow understanding. Found this https://sixe.eu/news/kvm-nested-vms-ibm-power-linux-lpar

That's exactly the same as x86. Nested virtualization support is almost entirely in the hypervisor.

x86 doesn't have a firmware hypervisor that allows splitting into LPARs.

That's showing 3 layers of nesting: LPAR, hypervisor, nested hypervisor

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#59

Post by rwmj »

fulafel wrote: post #56
rwmj wrote: post #46

Earlier quoted context omitted.

Because you want users to use virtualization for sandboxing without needing to make system-wide changes. That generally improves security overall. You might as well ask "why allow users to run anything at all?" since they can make system calls into a gigantic C program that is likely full of unknown bugs.

I get where you're coming from but I'd argue the kvm group is still better even when you automatically give all human users membership. You can then have less-privileged accounts for service roles, for example nginx doesn't need kvm acccess.

nginx might not, but some automated tool / cron job using libguestfs might. Kernel KVM has a very good record for security so it's not something to worry about, compared to (for example) lesser used drivers/filesystems or other dusty corners of the kernel.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#60

Post by bonzini »

tryauuum wrote: post #53
bonzini wrote: post #36

Earlier quoted context omitted.

KVM maintainer here. For what it's worth, this is a variant of a vulnerability discovered via fuzzing last April, CVE-2026-46113.

how dangerous is the vulnerability in practice? How hard is to actually achieve the KVM escape?

If you're a cloud provider, it's all hands on deck.

For everyone else it's dangerous enough to look seriously at getting an updated kernel or apply mitigations, especially since those are easy (disable nested virtualization, only requires restarting guests). Note that this is true even if you're not running guests, having a user running untrusted code and with access to /dev/kvm is enough.

If you're not running anything untrusted, you probably won't be affected but probably should still look at getting an updated kernel or apply mitigations.

It's the worst class of vulnerabilities for KVM in many years (this is the third variant, after CVE-2026-23401 which is a bit different and not guest teiggerable, and 46113 which I have already mentioned and is basically the same bug as this one), on the other hand it also says something about KVM that nothing similar was found in so many years. It's interesting that while this one was found with AI the first two were found with old school (albeit very sophisticated) fuzzing.

Post reply on HN