Fixing CVE-2026-53359 (Januscape) and CVE-2026-46113 on Talos Linux

Fixing CVE-2026-53359 (Januscape) and CVE-2026-46113 on Talos Linux

Update on CVE-2026-53359 (“Januscape”): the proper fix is here.

Our earlier mitigation was a hotfix — a temporary, forced measure. The proper fix is now available, so the hotfix is no longer needed.

TL;DR: Disabling nested virtualization is no longer needed. It was a hotfix, and for some setups it wasn’t even possible. The real fix is a kernel bump. If you already applied the hotfix, roll it back and upgrade instead.

What changed

When CVE-2026-53359 (Januscape) was disclosed on July 6, 2026 together with a working exploit, no Talos Linux image with a patched kernel existed yet. The only thing operators could do that day was reduce the attack surface by disabling nested virtualization at the kernel command line.

That window is closed. Patched stable kernels are out, and Talos now ships one. The fix is a kernel bump, not a config knob — once you are on a safe kernel, the vulnerable path is gone regardless of whether nested virtualization is enabled.

CVE-2026-53359 (Januscape) and the closely related CVE-2026-46113 are KVM x86 shadow-paging use-after-free bugs that let a guest VM escape to its host. Both affect Intel and AMD CPUs. In a Cozystack context this matters because tenant Kubernetes cluster nodes are KubeVirt VMs — so a malicious tenant with root inside its own VM is exactly the threat model these bugs enable.

The proper fix: a kernel bump

Both CVEs are fixed in Linux 6.18.38 and its backports. Make sure every node runs a patched kernel.

Safe kernel versions across all stable branches:

6.1.177 · 6.6.144 · 6.12.95 · 6.18.38 · 7.1.3 · 7.2-rc1
  • Generic Linux hosts (non-Talos): upgrade to Linux 6.18.38 or newer (or the patched version from your branch above), then reboot.
  • Talos Linux: upgrade to Talos v1.13.6, which ships Linux 6.18.38. Follow the runbook below.

If you applied the nested-virtualization hotfix, you can now roll it back after upgrading. You may keep it as an extra hardening measure if a workload doesn’t need nested virtualization, but it is no longer required for this CVE.

Why the hotfix wasn’t enough

The commonly suggested config mitigation — machine.install.extraKernelArgs: [kvm_intel.nested=0, kvm_amd.nested=0] — is silently ignored on systemd-boot / UKI nodes (the usual bare-metal UEFI case):

  • kvm_intel / kvm_amd are built into the Talos kernel, so modprobe.d and runtime /sys writes don’t apply (/sys/module/kvm_intel/parameters/nested is 0444); nested= is settable only via the kernel command line.
  • On systemd-boot the cmdline is baked into the signed UKI, so extraKernelArgs are dropped (Talos warns: extra kernel arguments are not supported when booting using SDBoot). grubUseUKICmdline: false only helps GRUB nodes.

That is precisely why “just disable nested virtualization” wasn’t a universal answer, and why a kernel bump is the real fix.

Runbook for Talos

1. Build an Image Factory schematic with your extensions

If your nodes use system extensions (drbd, zfs, firmware, GPU, ucode), declare them — Image Factory assembles the stock installer plus the official extensions, no custom image build required.

customization:
  systemExtensions:
    officialExtensions:
      - siderolabs/drbd
      - siderolabs/zfs
      - siderolabs/amd-ucode
      - siderolabs/intel-ucode
      - siderolabs/amdgpu
      - siderolabs/i915
      - siderolabs/bnx2-bnx2x
      - siderolabs/intel-ice-firmware
      - siderolabs/qlogic-firmware

curl -sX POST --data-binary @schematic.yaml https://factory.talos.dev/schematics
# -> {"id":"<SCHEMATIC_ID>"}

Trim the extension list to what your cluster actually uses.

2. Upgrade node by node

talosctl -n <NODE_IP> upgrade \
  --image factory.talos.dev/installer/<SCHEMATIC_ID>:v1.13.6

Roll one node at a time. On control-plane nodes, wait for etcd and your CSI/storage to be healthy between nodes. Talos only tests migrations between adjacent minors — from an old release, upgrade sequentially through each minor’s latest patch rather than jumping straight.

3. Verify

talosctl -n <NODE_IP> version                          # Server: v1.13.6
talosctl -n <NODE_IP> read /proc/sys/kernel/osrelease  # 6.18.38-talos
talosctl -n <NODE_IP> get extensions                   # your extensions present

kvm_intel.nested may stay Y — that’s expected. The vulnerable path is fixed in the kernel.

Ready installer (Cozystack extension set)

For the standard Cozystack extensions (drbd, zfs, amd/intel-ucode, amdgpu, i915, bnx2-bnx2x, intel-ice-firmware, qlogic-firmware), you can use this prebuilt schematic directly:

factory.talos.dev/installer/be66fdc8a38c2f517f33cba0a6daa7ab97ff87d51e8ca7d2160e45911ba09cf5:v1.13.6

References

Join the community