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

[Deerom]

Hi Everyone,

I've just read from the openwall-security mailling that there is a new Guest-to-Host KVM explot called 'Januscape'.
It seems to impact VMs which have the 'nested-virtualization' flag enabled, however for large multi-tenant service providers that may still be many.

Is Proxmox aware of this explot, and perhaps are aware of any possible mitigations?

Thank you in advance!
- Demian

 

[fabian]

yes, we are aware, and currently preparing fixed kernel packages. the only known mitigation at this time is disabling nested KVM.

 

[Deerom]

yes, we are aware, and currently preparing fixed kernel packages. the only known mitigation at this time is disabling nested KVM.

Hi Fabian,

Thank you for the quick response, we'll keep a close-eye on this thread & the security-advisory.
I'll mark this thread as completed.

 

[Gilou]

Mitigation on hosts not relying on nested virtualization is to indeed disable nested KVM through:

options kvm-intel nested=N
options kvm-amd nested=0

in /etc/modprobe.d/nested-kvm.conf

 

[Gilou]

Also, the PoC published doesn't manage to race on an AMD CPU, host running 7.0.14-3-pve. Do not run it on a production system...

 

[fabian]

fixed 6.8 and 7.0 kernels are on pve-test (proxmox-kernel-6.8.12-33-pve, proxmox-kernel-7.0.14-4-pve), 6.17 will follow shortly.

 

[jimmy1987]

how to only install a kernel from test? As using the enterprise repo I don't want all the test packages. Or is expected in the enterprise repo as well on a short period?

 

[Gilou]

it will reach the enterprise / pve-no-sub repositories shortly, I'm sure, but getting bits from pvetest is not exactly recommended. You could use pinning to only bring a specific package from that repository (and ignore the rest, or opt-in for those that matter). Not a good idea in production.

 

[jimmy1987]

Thought so, then I will wait for that

 

[fabian]

fixed kernels are now on pve-no-subscription

 

[wire2hire]

to be clear. is the nested flag default on? or must ist be set for ct / vms to be exploitable?

 

[Gilou]

to be clear. is the nested flag default on? or must ist be set for ct / vms to be exploitable?

it is on by default, per the kernel module settings, but it's not required at all. You only need it to emulate an hypervisor as a VM, so that qemu can itself use KVM and the virtualization extension of the CPU. It's not even available to a VM by default, as it requires either to explicitly present the flag, or use the "host" CPU model for the vCPU, which is not the default in Proxmox VE.

 

[wire2hire]

thanks for the exploration @Gilou . so , when in ct the nested flag not set and the vms have no "host cpu" model, the exploit can not be escape to the proxmox host on a vm with proxmox right?

 

[robertlukan]

Just installed the new kernel from pve-test. So far so good. This is just a standalone server, nothing fancy.

 

[daanw]

Kudos to @fabian & team for the quick response! Much appreciated.

 

[Johannes S]

the nested flag not set and the vms have no "host cpu" model, the exploit can not be escape to the proxmox host on a vm with proxmox right?

The nested flags of containers has nothing to do with nested virtualization. It's if you want to run containers inside of containers (e.g. podman or docker inside lxc ( which is NOT recommended) or lxcs inside lxcs (this should work usually)) or have a container with current systemd version since systemds sandboxing mechanisms do similiar things as containers https://wiki.archlinux.org/title/Systemd/Sandboxing ). This exploit is NOT about containers but virtual machines with the kernels kvm hypervisor. For virtual machines you need to change the CPU flags:



Normally the value of nested-virt is "default" which will then be on or not depending on the CPU model. If you want to be sure that it's disabled change the default to "off" and you will be fine, no matter which cpu version. BTW: The same flag is the one which causes Windows VMs with CPU type "host" to be slow due to enabled spectre/meltdown mitigations with "virtualization-based security". So for getting the most performance for windows it's a good idea to set the CPU type to "host" and disable "nested-virt" if you don't need Hyper-V, WSL or Windows Docker port (and why would you, with ProxmoxVE you can always start a Linux VM?)

 

[TheMrg]

thanks for the exploration @Gilou . so , when in ct the nested flag not set and the vms have no "host cpu" model, the exploit can not be escape to the proxmox host on a vm with proxmox right?

we have the same question. if we have no VM with CPU type "host", a root user on the VM can not escape?

 

[monkfish]

Kudos to @fabian & team for the quick response! Much appreciated.

I concur. Thanks team!
I am using nested virtualisation on my dev environment to provide a full-on hyper-v test lab. This does help.

Anecdotally (with absolutely no graph evidence to back this up for I am a doofus and not yet finished my monitoring!) a side-effect of specifically proxmox-kernel-7.0.14-4-pve package is that my fans on Dell Optiplex 7070 machines are running MUCH quieter! Definitely lower CPU usage, cannot explain the outcome but not complaining!

Thank you for Proxmox!