6 ms·

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

br0ceph 3mo ago
"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?
- bonzini 3mo ago
  Yes you can disable it via kernel module parameters kvm_intel.nested=0 or kvm_amd.nested=0.
- kurisufag 3mo ago
  Nested virtualization prompts the use of shadow paging (where the bug is), is my understanding, where non-nested cases use hardware accelerated translation instead.
rvz 3mo ago
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 distant future. The first commit that introduced this vulnerability was in 2010. [1] So it was undiscovered for 16 years until now [2]. It was only a matter of time that a vulnerability in KVM would appear. This one is really not good as it is the first KVM guest-to-host exploit working on both AMD and Intel. [0] https://github.com/V4bel/Januscape/blob/main/assets/write-up.md https://github.com/V4bel/Januscape/blob/main/assets/write-up... [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2032a93d66fa https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81ccda30b4e8 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- TedDoesntTalk 3mo ago
  > So it was undiscovered for 16 years until now Publicly undiscovered
- huflungdung 3mo ago
  [dead]
- bonzini 3mo ago
  KVM maintainer here. For what it's worth, this is a variant of a vulnerability discovered via fuzzing last April, CVE-2026-46113.
  - tryauuum 3mo ago
    how dangerous is the vulnerability in practice? How hard is to actually achieve the KVM escape?
    - bonzini 3mo ago
      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.
huflungdung 3mo ago
[dead]
TZubiri 3mo ago
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 one dedicated server So if your hourly is worth anywhere upwards of 5$/hr, and your project has any semblance of seriousness, just use a dedicated server, and avoid a whole class of LPE vulnerabilities just to save some $. Businesses have expenses, let's stop pretending that all of these non dedicated server infrastructures are serious. Shell out 200$/month or stick to hobby status. No, I don't sell dedicated servers, but I should
- Scotrix 3mo ago
  I run 3 servers for 200 EUR, thanks to Hetzner, exactly for this reason (and I’m cheap and I never understood cloud/services like Vercel and Railway as serious alternatives ;-)).
- antonvs 3mo ago
  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 you don’t have to. This is as serious as it gets in business. Managing your own hardware makes very little sense for many, if not most companies.
  - tetha 3mo ago
    Own hardware has a weird scaling curve. It does not make sense for a lot of time and scaling. You need 3+ people maintaining it, you have upfront costs in the hundreds of thousands of euros on the very lower end. If you don't utilize that money spent, sucks to be you. You have planning times in the area of months, not hours, unless you keep capacity you don't use around (rackspace, cabling, power/cooling capacity). On the other hand, if you have that hardware management running, it's very amazing. Before the AI nuke, We were looking at moving various systems fully bare metal, because it would simplify management on both sides a lot, and a common statement I heard is "We don't deal with systems that small. If we do bare metal container hosting, we don't measure in dozens of gigabytes of memory. Your business case validates that investment. Here is btw three test systems about double your requirement, just old". Before the AI nonsense (HBM Memory Demand -> RAM & SSD prices), this would result in very competitive hosting costs after some scale, when amortized across 5 years and then tossed into the testing environment until it stops functioning. And these testing environments allow for a lot of experimentation and failover testing. Though now it's all very different and not clear.
rballpug 3mo ago
KVM, or x86 identified mail validation.
codedokode 3mo ago
> 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?
- tryauuum 3mo ago
  Not all device files, only /dev/kvm. I assume the logic was "with /dev/kvm access the user can ...allocate memory and execute code, which they already can, so why not allow it?". Could also make rootless isolation easier
  - codedokode 3mo ago
    Different kernel modules might have different vulnerabilities.
- cyberax 3mo ago
  ??? That's been the case forever: /dev/null, /dev/zero, /dev/stdin, ...
  - inigyou 3mo ago
    /dev/stdin is a symlink to /proc/self/fd/0
- colechristensen 3mo ago
  Very many "devices" aren't at all device-like.
- Intralexical 3mo ago
  Because if /dev/kvm isn't accessible to unprivileged users, then people will start using `sudo` to run anything involving virtualization, which would be much worse for security overall.
  - CoastalCoder 3mo ago
trebligdivad 3mo ago
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 nesting is a bad idea for public VM hosts.
- deleted 3mo ago
  [deleted]
- iririririr 3mo ago
  but that's the entire point of kvm. that leak is the feature! that's how you get the performance boost.
- stinkbeetle 3mo ago
  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.
  - nijave 3mo ago
    IBM mainframes might but I have a very shallow understanding. Found this https://sixe.eu/news/kvm-nested-vms-ibm-power-linux-lpar https://sixe.eu/news/kvm-nested-vms-ibm-power-linux-lpar
    - bonzini 3mo ago
      That's exactly the same as x86. Nested virtualization support is almost entirely in the hypervisor.
CoastalCoder 3mo ago
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?
- bonzini 3mo ago
  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.
eqvinox 3mo ago
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.)
- bonzini 3mo ago
  KVM maintainer here, yes it is.
anonym29 3mo ago
xenchads dabbing on kvmvirgins once again

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

bonzini 3mo ago
Yes you can disable it via kernel module parameters kvm_intel.nested=0 or kvm_amd.nested=0.
kurisufag 3mo ago
Nested virtualization prompts the use of shadow paging (where the bug is), is my understanding, where non-nested cases use hardware accelerated translation instead.

rvz 3mo ago

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 distant future. The first commit that introduced this vulnerability was in 2010. [1] So it was undiscovered for 16 years until now [2]. It was only a matter of time that a vulnerability in KVM would appear. This one is really not good as it is the first KVM guest-to-host exploit working on both AMD and Intel. [0] https://github.com/V4bel/Januscape/blob/main/assets/write-up.md https://github.com/V4bel/Januscape/blob/main/assets/write-up... [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2032a93d66fa https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81ccda30b4e8 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

TedDoesntTalk 3mo ago
> So it was undiscovered for 16 years until now Publicly undiscovered
huflungdung 3mo ago
[dead]
bonzini 3mo ago
KVM maintainer here. For what it's worth, this is a variant of a vulnerability discovered via fuzzing last April, CVE-2026-46113.
- tryauuum 3mo ago
  how dangerous is the vulnerability in practice? How hard is to actually achieve the KVM escape?
  - bonzini 3mo ago
    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.

huflungdung 3mo ago

[dead]

TZubiri 3mo ago

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 one dedicated server So if your hourly is worth anywhere upwards of 5$/hr, and your project has any semblance of seriousness, just use a dedicated server, and avoid a whole class of LPE vulnerabilities just to save some $. Businesses have expenses, let's stop pretending that all of these non dedicated server infrastructures are serious. Shell out 200$/month or stick to hobby status. No, I don't sell dedicated servers, but I should

Scotrix 3mo ago
I run 3 servers for 200 EUR, thanks to Hetzner, exactly for this reason (and I’m cheap and I never understood cloud/services like Vercel and Railway as serious alternatives ;-)).
antonvs 3mo ago
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 you don’t have to. This is as serious as it gets in business. Managing your own hardware makes very little sense for many, if not most companies.
- tetha 3mo ago
  Own hardware has a weird scaling curve. It does not make sense for a lot of time and scaling. You need 3+ people maintaining it, you have upfront costs in the hundreds of thousands of euros on the very lower end. If you don't utilize that money spent, sucks to be you. You have planning times in the area of months, not hours, unless you keep capacity you don't use around (rackspace, cabling, power/cooling capacity). On the other hand, if you have that hardware management running, it's very amazing. Before the AI nuke, We were looking at moving various systems fully bare metal, because it would simplify management on both sides a lot, and a common statement I heard is "We don't deal with systems that small. If we do bare metal container hosting, we don't measure in dozens of gigabytes of memory. Your business case validates that investment. Here is btw three test systems about double your requirement, just old". Before the AI nonsense (HBM Memory Demand -> RAM & SSD prices), this would result in very competitive hosting costs after some scale, when amortized across 5 years and then tossed into the testing environment until it stops functioning. And these testing environments allow for a lot of experimentation and failover testing. Though now it's all very different and not clear.

rballpug 3mo ago

KVM, or x86 identified mail validation.

codedokode 3mo ago

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

tryauuum 3mo ago
Not all device files, only /dev/kvm. I assume the logic was "with /dev/kvm access the user can ...allocate memory and execute code, which they already can, so why not allow it?". Could also make rootless isolation easier
- codedokode 3mo ago
  Different kernel modules might have different vulnerabilities.
cyberax 3mo ago
??? That's been the case forever: /dev/null, /dev/zero, /dev/stdin, ...
- inigyou 3mo ago
  /dev/stdin is a symlink to /proc/self/fd/0
colechristensen 3mo ago
Very many "devices" aren't at all device-like.
Intralexical 3mo ago
Because if /dev/kvm isn't accessible to unprivileged users, then people will start using `sudo` to run anything involving virtualization, which would be much worse for security overall.
- CoastalCoder 3mo ago

trebligdivad 3mo ago

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 nesting is a bad idea for public VM hosts.

deleted 3mo ago
[deleted]
iririririr 3mo ago
but that's the entire point of kvm. that leak is the feature! that's how you get the performance boost.
stinkbeetle 3mo ago
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.
- nijave 3mo ago
  IBM mainframes might but I have a very shallow understanding. Found this https://sixe.eu/news/kvm-nested-vms-ibm-power-linux-lpar https://sixe.eu/news/kvm-nested-vms-ibm-power-linux-lpar
  - bonzini 3mo ago
    That's exactly the same as x86. Nested virtualization support is almost entirely in the hypervisor.

CoastalCoder 3mo ago

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?

bonzini 3mo ago
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.

eqvinox 3mo ago

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.)

bonzini 3mo ago
KVM maintainer here, yes it is.

anonym29 3mo ago

xenchads dabbing on kvmvirgins once again