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

31–40 of 67 posts

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

#31

Post by dboreham »

zuzululu wrote: post #17
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…

i dont get this dedicated servers = hobby mentality you can do a ton with just a couple of dedicated servers with the redundancy you need

Three really, but otherwise yes.

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

#32

Post by [deleted] »

trebligdivad wrote: post #20

Nested virt on x86 is curiously painful; you'd kind of think each layer would be isolated, so that the L0 (hardware) would only have to worry about it's VM (L1), and L1 would have to worry about it's VM (L2); but nope - the L0 top level hypervisor sees faults from the L2 and has to figure out that they are actually L2 not L0. IMHO the extra complexity (and historical flakiness of it) - makes me say that enabling nest…

[deleted]

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

#33

Post by [deleted] »

zuzululu wrote: post #17
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…

i dont get this dedicated servers = hobby mentality you can do a ton with just a couple of dedicated servers with the redundancy you need

[deleted]

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

#35

Post by fulafel »

codedokode wrote: post #12

> LPE: On distributions such as RHEL, /dev/kvm is world-writable (0666), so an unprivileged user can also use this vulnerability as a reliable LPE to gain root. Why on Linux device files are accessible by untrusted applications?

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?

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

#36

Post by bonzini »

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.

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

#37

Post by bonzini »

CoastalCoder wrote: post #27

Some of the comments here talk about the risk this poses for multi tenant vm providers. Wouldn't this also be a risk for people using VMs to sandbox untrusted code running on trusted hosts?

In that case you'd have to combine this vulnerability with a local privilege escalation to reach guest kernel mode.

Also the vulnerability requires enabling nested virtualization on the VM.

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

#38

Post by quotemstr »

msm_ wrote: post #29
CoastalCoder wrote: post #26

Earlier quoted context omitted.

I'm just starting to read up on capabilities-based security in Linux. Would they potentially be a solution to sudo's all-or-nothing granularity in this domain?

Linux capabilities have many problems (they are too coarse-grained and too many capabilities are root-equivalent). But anyway this is an overkill in this case probably. In may distributions access to /dev/kvm is guarded by membership in the kvm group - no need for new capability, just regular old filesystem permissions.

> /dev/kvm is guarded by membership in the kvm group - no need for new capability, just regular old filesystem permissions.

Which is precisely why many kinds of kernel feature should be exposed as operations on device nodes, not as system calls usable out of thin air. UGO and ACL permissions work on device nodes!

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

#39

Post by bonzini »

br0ceph wrote: post #2

"If you operate an x86 KVM host that accepts multi-tenant guests and supports nested virtualization, or use an instance on top of one" does this mean that you must have nested virtualization enabled to br vulnerable. does disabling this feature in the host os or bios, make you immune to this bug?

Yes you can disable it via kernel module parameters kvm_intel.nested=0 or kvm_amd.nested=0.

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

#40

Post by iririririr »

trebligdivad wrote: post #20

Nested virt on x86 is curiously painful; you'd kind of think each layer would be isolated, so that the L0 (hardware) would only have to worry about it's VM (L1), and L1 would have to worry about it's VM (L2); but nope - the L0 top level hypervisor sees faults from the L2 and has to figure out that they are actually L2 not L0. IMHO the extra complexity (and historical flakiness of it) - makes me say that enabling nest…

but that's the entire point of kvm. that leak is the feature! that's how you get the performance boost.
Post reply on HN