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.
12 hours ago [-]
stinkbeetle 9 hours 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 7 hours ago [-]
IBM mainframes might but I have a very shallow understanding.
That's exactly the same as x86. Nested virtualization support is almost entirely in the hypervisor.
nijave 3 hours ago [-]
x86 doesn't have a firmware hypervisor that allows splitting into LPARs.
That's showing 3 layers of nesting: LPAR, hypervisor, nested hypervisor
bonzini 7 hours ago [-]
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.
iririririr 10 hours ago [-]
but that's the entire point of kvm. that leak is the feature! that's how you get the performance boost.
br0ceph 1 days 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?
kurisufag 24 hours 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.
bonzini 12 hours ago [-]
Yes you can disable it via kernel module parameters kvm_intel.nested=0 or kvm_amd.nested=0.
eqvinox 8 hours 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 7 hours ago [-]
KVM maintainer here, yes it is.
CoastalCoder 17 hours 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 12 hours 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.
rvz 23 hours 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.
For what it's worth, this is a variant of a vulnerability discovered via fuzzing last April, CVE-2026-46113.
tryauuum 5 hours ago [-]
how dangerous is the vulnerability in practice? How hard is to actually achieve the KVM escape?
bonzini 35 minutes 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.
TedDoesntTalk 20 hours ago [-]
> So it was undiscovered for 16 years until now
Publicly undiscovered
huflungdung 23 hours ago [-]
[dead]
codedokode 21 hours 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 21 hours 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 19 hours ago [-]
Different kernel modules might have different vulnerabilities.
Intralexical 19 hours 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 17 hours ago [-]
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?
msm_ 17 hours ago [-]
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.
Intralexical 15 hours ago [-]
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.
codedokode 9 hours ago [-]
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.
quotemstr 12 hours ago [-]
> /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!
yjftsjthsd-h 18 hours ago [-]
1: As siblings note, some device files are wide open, some are limited to a given user group, and some are root-only.
2: Because it's desirable for users to be able to run VMs.
fulafel 12 hours ago [-]
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?
rwmj 7 hours ago [-]
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.
fulafel 4 hours ago [-]
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.
rwmj 3 hours ago [-]
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.
codedokode 9 hours ago [-]
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?
fulafel 4 hours ago [-]
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.
12 hours ago [-]
cyberax 21 hours ago [-]
???
That's been the case forever: /dev/null, /dev/zero, /dev/stdin, ...
inigyou 7 hours ago [-]
/dev/stdin is a symlink to /proc/self/fd/0
colechristensen 20 hours ago [-]
Very many "devices" aren't at all device-like.
TZubiri 23 hours 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
nijave 4 hours ago [-]
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.
marysol5 6 hours ago [-]
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
Scotrix 22 hours 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 22 hours 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.
codedokode 20 hours ago [-]
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 requires people, and people cost money.
People in AWS also cost money and guess who is going to cover this cost?
nijave 4 hours ago [-]
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)
marysol5 6 hours ago [-]
>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.
cyberax 20 hours ago [-]
Suppose that you are a midsize company or a b2b service, so you want to make sure that your service has minimum downtime.
This means that you need sysadmins in close proximity to your hardware to do hardware swapping/troubleshooting. Or you need to engineer your system to not have a SPOF (which is not easy). So you're looking at employing at least 2 engineers near your datacenter.
calvinmorrison 18 hours ago [-]
Really? We basically never go onsight. Ticket in with the colo and they can help.
cyberax 17 hours ago [-]
That really works well while you have a rack or so. Afterwards, you really need people who know all the details of networking and storage. Especially if you're designing something without a SPOF.
What's changing is the scope of things that you can run on that one rack. 15 years ago, I was running clusters of 30 computers to do things that I now can do with 1.
calvinmorrison 3 minutes ago [-]
Nope... last time i was on site was when we migrated data centers. a dozen racks.
tetha 21 hours 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.
zuzululu 20 hours ago [-]
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
12 hours ago [-]
dboreham 14 hours ago [-]
Three really, but otherwise yes.
TZubiri 19 hours ago [-]
There seems to be some confusion, although one other user interpreted the same thing, I still believe it's a misinterpretation.
I said dedicated servers, I never said anything about owning or managing the hardware. You can rent a dedicated server.
The decision to virtualize and the decision to own the hardware are separate decisions.
rballpug 21 hours ago [-]
KVM, or x86 identified mail validation.
huflungdung 23 hours ago [-]
[dead]
Rendered at 17:59:02 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
Found this https://sixe.eu/news/kvm-nested-vms-ibm-power-linux-lpar
That's showing 3 layers of nesting: LPAR, hypervisor, nested hypervisor
Intel and AMD both have some small amount of acceleration of nested virtualization, respectively with shadow VMCS and virtualized VMLOAD/VMSAVE.
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?
(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.)
Wouldn't this also be a risk for people using VMs to sandbox untrusted code running on trusted hosts?
Also the vulnerability requires enabling nested virtualization on the VM.
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...
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
For what it's worth, this is a variant of a vulnerability discovered via fuzzing last April, CVE-2026-46113.
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.
Publicly undiscovered
Why on Linux device files are accessible by untrusted applications?
Would they potentially be a solution to sudo's all-or-nothing granularity in this domain?
So as a responsible user I am slowly writing my own sandboxes, struggling with lack of documentation and designing workarounds.
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!
2: Because it's desirable for users to be able to run VMs.
That's been the case forever: /dev/null, /dev/zero, /dev/stdin, ...
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
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.
All of these layers are a form of risk
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.
Also if you have several servers you do not need to hire a full-time sysadmin.
> Managing a non-trivial hardware fleet requires people, and people cost money.
People in AWS also cost money and guess who is going to cover this cost?
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)
Or because it's cost-effective to slice up your infrastructure and sell off the bits you're not using right now.
This means that you need sysadmins in close proximity to your hardware to do hardware swapping/troubleshooting. Or you need to engineer your system to not have a SPOF (which is not easy). So you're looking at employing at least 2 engineers near your datacenter.
What's changing is the scope of things that you can run on that one rack. 15 years ago, I was running clusters of 30 computers to do things that I now can do with 1.
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.
you can do a ton with just a couple of dedicated servers with the redundancy you need
I said dedicated servers, I never said anything about owning or managing the hardware. You can rent a dedicated server.
The decision to virtualize and the decision to own the hardware are separate decisions.