diff --git a/content/en/blog/2026-07-14-fixing-cve-2026-53359-januscape-talos-linux/index.md b/content/en/blog/2026-07-14-fixing-cve-2026-53359-januscape-talos-linux/index.md new file mode 100644 index 00000000..b869d9a9 --- /dev/null +++ b/content/en/blog/2026-07-14-fixing-cve-2026-53359-januscape-talos-linux/index.md @@ -0,0 +1,126 @@ +--- +title: "Fixing CVE-2026-53359 (Januscape) and CVE-2026-46113 on Talos Linux" +slug: fixing-cve-2026-53359-januscape-talos-linux +date: 2026-07-14 +author: "lexfrei" +description: "The proper fix for CVE-2026-53359 (Januscape) and CVE-2026-46113 is a kernel bump, not disabling nested virtualization — with a Talos Linux upgrade runbook." +images: + - "januscape-talos-fix.png" +article_types: + - how-to + - talos +topics: + - security + - talos + - kubevirt + - platform + +--- + +![Fixing CVE-2026-53359 (Januscape) and CVE-2026-46113 on Talos Linux](januscape-talos-fix.png) + +**Update on CVE-2026-53359 ("Januscape"): the proper fix is here.** + +Our [earlier mitigation](https://nvd.nist.gov/vuln/detail/CVE-2026-53359) 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)](https://nvd.nist.gov/vuln/detail/CVE-2026-53359) 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](https://nvd.nist.gov/vuln/detail/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](https://factory.talos.dev) assembles the stock installer plus the official extensions, no custom image build required. + +```yaml +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 +``` + +```bash +curl -sX POST --data-binary @schematic.yaml https://factory.talos.dev/schematics +# -> {"id":""} +``` + +Trim the extension list to what your cluster actually uses. + +### 2. Upgrade node by node + +```bash +talosctl -n upgrade \ + --image factory.talos.dev/installer/: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 + +```bash +talosctl -n version # Server: v1.13.6 +talosctl -n read /proc/sys/kernel/osrelease # 6.18.38-talos +talosctl -n 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 + +- [CVE-2026-53359 (Januscape) — NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-53359) +- [CVE-2026-46113 — NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-46113) +- [Talos bootloader / UKI cmdline](https://docs.siderolabs.com/talos/v1.13/platform-specific-installations/bare-metal-platforms/bootloader) +- [Talos Image Factory](https://factory.talos.dev) + +### Join the community + +- Telegram [group](https://t.me/cozystack) +- Slack [group](https://kubernetes.slack.com/archives/C06L3CPRVN1) (Get invite at [https://slack.kubernetes.io](https://slack.kubernetes.io)) +- [Community Meeting Calendar](https://calendar.google.com/calendar?cid=ZTQzZDIxZTVjOWI0NWE5NWYyOGM1ZDY0OWMyY2IxZTFmNDMzZTJlNjUzYjU2ZGJiZGE3NGNhMzA2ZjBkMGY2OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t) diff --git a/content/en/blog/2026-07-14-fixing-cve-2026-53359-januscape-talos-linux/januscape-talos-fix.png b/content/en/blog/2026-07-14-fixing-cve-2026-53359-januscape-talos-linux/januscape-talos-fix.png new file mode 100644 index 00000000..1ab58b8b Binary files /dev/null and b/content/en/blog/2026-07-14-fixing-cve-2026-53359-januscape-talos-linux/januscape-talos-fix.png differ