[SOLVED] Are there mitigations available for CVE-2026-53359 'Januscape'

[leesteken]

Is this a side-effect of deactivating nested KVM and migrating a VM from a node with active nested KVM to a nested KVM disabled node? All VMs are cputype `host`, non is using nested KVM is in running VMs inside the VMs.

Migrating VMs from one host to another where the host have different capabilities/flags is always problematic. Because you use type host, you expose all CPU flags which includes nested-virt (or the AMD/Intel specific one) and this type of CPU change cannot be handled inside a VM without a restart. In short: this is to be expected to fail (but the message it not at all clear).

 

[nick-a]

Just to confirm, if the CPU type for a guest VM isn't set to 'host' then it's safe? What if it's set to a generation, like 'IvyBridge' or 'Broadwell'? This is on 7.4, nodes that aren't updated yet.

 

[leesteken]

Just to confirm, if the CPU type for a guest VM isn't set to 'host' then it's safe? What if it's set to a generation, like 'IvyBridge' or 'Broadwell'? This is on 7.4, nodes that aren't updated yet.

This has been discussed before and I think it is also in the manual. When you have a heterogeneous cluster then you need to use a CPU type that is supported on every node. Or HA rules to prevent problematic migrations (but that is hard to keep up to date manually). PVE 7 has been end of life and out of support already for two years.

EDIT: I thought you were asking if the live migration is safe. Maybe you were asking if you were safe from the exploit?

 

[nick-a]

Fully aware of all that thanks, this old cluster had a few E5-2690 v2 servers hence all VMs are set to IvyBridge, hence the question. I'm not seeing anything in the manual that answers what I've asked? Bearing in mind the seriousness of this, I'm just trying to double check, some of the posts so far about it are a bit vague.

 

[fabian]

7.x is out of support and affected by lots of security issues by now, you cannot use it to run untrusted workloads irrespective of whether your configuration is safe or not w.r.t. this particular vulnerability. if you don't have nesting enabled, the issue at hand is mitigated.

 

[nick-a]

Thanks Fabian, if the CPU type is set to 'IvyBridge' does that also mitigate it? As others have said it has to be 'host' to be vulnerable, and that anything else doesn't expose the required CPU flag to enable nested virt.

 

[fabian]

I don't know by heart (and won't look it up given the EOL status) when the streamlined support for that got added, but you can have non-host CPU models supporting nested virtualization by passing the required flags to the VM, so the CPU model alone is not a 100% indicator.

 

[nick-a]

Both our 8.4 and 9.2 clusters also have Ivybridge as an option so it's still a reasonable question...it's just the flag is exposed.

Anyway, update for anyone else curious: running egrep '(vmx|svm)' --color=always /proc/cpuinfo inside the VMs shows nothing on VMs with various non 'host' CPU generations set, so I'm assuming they're not vulnerable to Januscape for now.

 

[Johannes S]

Why are people asking about CPU models when there is a proven way to enable this migitigation in the UI via CPU flags? You might be wrong whether a certain cpu model has nested virtualization, disabling it in the options guarantees that it's not enabled at all. And if you happen to have a lot of VMs, the whole process of enabling can be scripted

 

[nick-a]

Personally I was only asking because I have a small older cluster that's being shut down in a couple of weeks, the flag isn't exposed in the GUI (because it's old), and I wanted to check if I had to do anything whatsoever to mitigate this particular vulnerability, I didn't want to invest any time on something that's being shutdown anyway shortly. Newer stuff is just update and reboot, or flags, fine, all good.