Live data from Hacker News

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

github.com

41–50 of 67 posts

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

#41
post #29

Earlier quoted context omitted.

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.

Would capabilities enable granting access to specific programs and not just users? Like using AppArmor profiles. So QEMU, gVisor, Docker etc. can still use KVM for unprivileged users, but malware wouldn't be able to access it directly.

That's the problem with many Linux distributions - their developers assume that you trust programs you run and if you run malware it is your fault. But you cannot trust commercial and closed-source programs so Linux is not ready for using them. Instead of solving the problem they simply make it user's responsibility.

So as a responsible user I am slowly writing my own sandboxes, struggling with lack of documentation and designing workarounds.

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

#42
post #35

> 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?

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?

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

#43

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…

The alternatives are the L0 emulates a hypervisor-privileged mode to the L1 which would be a performance cost (and does not really avoid the problem since the L0 would have to emulate vmenter/vmrun and therefore be aware of the L2 anyway, or the hardware would have to provide some nested virtualization facility which seems like it would be complicated and expensive for little benefit, though I could be mistaken.

Does anything do a "real" nested virtualization in hardware? s390 might but I know ~nothing about it and it probably does not expose its bare metal hardware layers to Linux/KVM anyway.

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

#44
Anyone know if "-cpu ${CPU},vmx=off,svm=off" in QEMU is a safe workaround for this?

(To disable nested virtualization on a per-VM basis. Only against exploitation from within that specific VM, obviously does nothing against users with access to /dev/kvm on the host.)

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

#45
post #14

> 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?

??? That's been the case forever: /dev/null, /dev/zero, /dev/stdin, ...

/dev/stdin is a symlink to /proc/self/fd/0

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

#46
post #35

> 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?

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.

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

#47
post #44

Anyone know if "-cpu ${CPU},vmx=off,svm=off" in QEMU is a safe workaround for this? (To disable nested virtualization on a per-VM basis. Only against exploitation from within that specific VM, obviously does nothing against users with access to /dev/kvm on the host.)

KVM maintainer here, yes it is.

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

#48

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…

The alternatives are the L0 emulates a hypervisor-privileged mode to the L1 which would be a performance cost (and does not really avoid the problem since the L0 would have to emulate vmenter/vmrun and therefore be aware of the L2 anyway, or the hardware would have to provide some nested virtualization facility which seems like it would be complicated and expensive for little benefit, though I could be mistaken. Does…

IBM mainframes might but I have a very shallow understanding.

Found this https://sixe.eu/news/kvm-nested-vms-ibm-power-linux-lpar

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

#49

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…

The alternatives are the L0 emulates a hypervisor-privileged mode to the L1 which would be a performance cost (and does not really avoid the problem since the L0 would have to emulate vmenter/vmrun and therefore be aware of the L2 anyway, or the hardware would have to provide some nested virtualization facility which seems like it would be complicated and expensive for little benefit, though I could be mistaken. Does…

No, even s390 needs shadow paging.

Intel and AMD both have some small amount of acceleration of nested virtualization, respectively with shadow VMCS and virtualized VMLOAD/VMSAVE.

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

#50
post #48

Earlier quoted context omitted.

The alternatives are the L0 emulates a hypervisor-privileged mode to the L1 which would be a performance cost (and does not really avoid the problem since the L0 would have to emulate vmenter/vmrun and therefore be aware of the L2 anyway, or the hardware would have to provide some nested virtualization facility which seems like it would be complicated and expensive for little benefit, though I could be mistaken. Does…

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.
Post reply on HN