From da0b834dcca062af9f0b497a0012c4c086bc6a14 Mon Sep 17 00:00:00 2001 From: Aleksei Sviridkin Date: Thu, 9 Jul 2026 15:53:44 +0300 Subject: [PATCH 1/4] docs: keep alert bodies out of indented code blocks in install guides Hugo renders the inner text of a {{% alert %}} shortcode as markdown on its own. Inside an ordered-list item the body carried the item's four-space content indent, which markdown reads as an indented code block, so the alert displayed its own raw markup instead of the note. Flush the body to column zero and leave only the shortcode tags indented, so the alert still belongs to the list item and the surrounding list is not split in two. Signed-off-by: Aleksei Sviridkin --- content/en/docs/next/install/kubernetes/talos-bootstrap.md | 2 +- content/en/docs/next/install/kubernetes/talosctl.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/next/install/kubernetes/talos-bootstrap.md b/content/en/docs/next/install/kubernetes/talos-bootstrap.md index 1678b79e..b0443a57 100644 --- a/content/en/docs/next/install/kubernetes/talos-bootstrap.md +++ b/content/en/docs/next/install/kubernetes/talos-bootstrap.md @@ -103,7 +103,7 @@ talos-bootstrap --help ``` {{% alert title="Do not change op: on these entries" color="warning" %}} - Talos rejects `op: create` for any file outside `/var`, returning the error `create operation not allowed outside of /var` — the only exception is the special-cased `/etc/cri/conf.d/20-customization.part`. Because `/etc/lvm/lvm.conf` already exists on the node, it must use `op: overwrite`. Changing the op (or pointing `create` at another `/etc` path) fails the `WriteUserFiles` boot step: the node pauses and enters a reboot loop, and `talosctl bootstrap` reports only `bootstrap is not available yet` with no obvious cause. +Talos rejects `op: create` for any file outside `/var`, returning the error `create operation not allowed outside of /var` — the only exception is the special-cased `/etc/cri/conf.d/20-customization.part`. Because `/etc/lvm/lvm.conf` already exists on the node, it must use `op: overwrite`. Changing the op (or pointing `create` at another `/etc` path) fails the `WriteUserFiles` boot step: the node pauses and enters a reboot loop, and `talosctl bootstrap` reports only `bootstrap is not available yet` with no obvious cause. {{% /alert %}} 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: diff --git a/content/en/docs/next/install/kubernetes/talosctl.md b/content/en/docs/next/install/kubernetes/talosctl.md index 7e9adc94..547dc860 100644 --- a/content/en/docs/next/install/kubernetes/talosctl.md +++ b/content/en/docs/next/install/kubernetes/talosctl.md @@ -127,7 +127,7 @@ Discovered open port 50000/tcp on 192.168.123.13 ``` {{% alert title="Do not change op: on these entries" color="warning" %}} - Talos rejects `op: create` for any file outside `/var`, returning the error `create operation not allowed outside of /var` — the only exception is the special-cased `/etc/cri/conf.d/20-customization.part`. Because `/etc/lvm/lvm.conf` already exists on the node, it must use `op: overwrite`. Changing the op (or pointing `create` at another `/etc` path) fails the `WriteUserFiles` boot step: the node pauses and enters a reboot loop, and `talosctl bootstrap` reports only `bootstrap is not available yet` with no obvious cause. +Talos rejects `op: create` for any file outside `/var`, returning the error `create operation not allowed outside of /var` — the only exception is the special-cased `/etc/cri/conf.d/20-customization.part`. Because `/etc/lvm/lvm.conf` already exists on the node, it must use `op: overwrite`. Changing the op (or pointing `create` at another `/etc` path) fails the `WriteUserFiles` boot step: the node pauses and enters a reboot loop, and `talosctl bootstrap` reports only `bootstrap is not available yet` with no obvious cause. {{% /alert %}} 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: From 2e6346f0e199df4cb04f125c9453654e41725951 Mon Sep 17 00:00:00 2001 From: Aleksei Sviridkin Date: Thu, 9 Jul 2026 15:58:17 +0300 Subject: [PATCH 2/4] docs: point CVE-2026-53359 at the Talos v1.13.6 kernel fix CVE-2026-53359 ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. The complete fix needs both upstream patches, which first meet in Linux 6.18.38 and so in Talos v1.13.6. These docs versions install Talos from the 1.13 line, so moving the image tag reaches the fixed kernel. Say that, and say that nested virtualization stays enabled: the kernel fix removes the bug itself, so there is no reason to take the feature away from workloads that depend on it. Signed-off-by: Aleksei Sviridkin --- content/en/docs/next/install/kubernetes/talos-bootstrap.md | 4 ++++ content/en/docs/next/install/kubernetes/talosctl.md | 4 ++++ content/en/docs/v1.4/install/kubernetes/talos-bootstrap.md | 4 ++++ content/en/docs/v1.4/install/kubernetes/talosctl.md | 4 ++++ content/en/docs/v1.5/install/kubernetes/talos-bootstrap.md | 4 ++++ content/en/docs/v1.5/install/kubernetes/talosctl.md | 4 ++++ 6 files changed, 24 insertions(+) diff --git a/content/en/docs/next/install/kubernetes/talos-bootstrap.md b/content/en/docs/next/install/kubernetes/talos-bootstrap.md index b0443a57..484999f4 100644 --- a/content/en/docs/next/install/kubernetes/talos-bootstrap.md +++ b/content/en/docs/next/install/kubernetes/talos-bootstrap.md @@ -102,6 +102,10 @@ talos-bootstrap --help - 10.96.0.0/16 ``` + {{% alert title="Update Talos to v1.13.6 or newer (CVE-2026-53359)" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both are fixed in the kernel, and Talos v1.13.6 is the first release that carries both fixes — it ships Linux 6.18.38. If the image tag above resolves to an earlier release, set it to `v1.13.6` or newer. Nested virtualization stays enabled: the kernel fix removes the bug itself, so workloads that rely on nested virtualization keep working. + {{% /alert %}} + {{% alert title="Do not change op: on these entries" color="warning" %}} Talos rejects `op: create` for any file outside `/var`, returning the error `create operation not allowed outside of /var` — the only exception is the special-cased `/etc/cri/conf.d/20-customization.part`. Because `/etc/lvm/lvm.conf` already exists on the node, it must use `op: overwrite`. Changing the op (or pointing `create` at another `/etc` path) fails the `WriteUserFiles` boot step: the node pauses and enters a reboot loop, and `talosctl bootstrap` reports only `bootstrap is not available yet` with no obvious cause. {{% /alert %}} diff --git a/content/en/docs/next/install/kubernetes/talosctl.md b/content/en/docs/next/install/kubernetes/talosctl.md index 547dc860..5a1652a1 100644 --- a/content/en/docs/next/install/kubernetes/talosctl.md +++ b/content/en/docs/next/install/kubernetes/talosctl.md @@ -126,6 +126,10 @@ Discovered open port 50000/tcp on 192.168.123.13 - 10.96.0.0/16 ``` + {{% alert title="Update Talos to v1.13.6 or newer (CVE-2026-53359)" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both are fixed in the kernel, and Talos v1.13.6 is the first release that carries both fixes — it ships Linux 6.18.38. If the image tag above resolves to an earlier release, set it to `v1.13.6` or newer. Nested virtualization stays enabled: the kernel fix removes the bug itself, so workloads that rely on nested virtualization keep working. + {{% /alert %}} + {{% alert title="Do not change op: on these entries" color="warning" %}} Talos rejects `op: create` for any file outside `/var`, returning the error `create operation not allowed outside of /var` — the only exception is the special-cased `/etc/cri/conf.d/20-customization.part`. Because `/etc/lvm/lvm.conf` already exists on the node, it must use `op: overwrite`. Changing the op (or pointing `create` at another `/etc` path) fails the `WriteUserFiles` boot step: the node pauses and enters a reboot loop, and `talosctl bootstrap` reports only `bootstrap is not available yet` with no obvious cause. {{% /alert %}} diff --git a/content/en/docs/v1.4/install/kubernetes/talos-bootstrap.md b/content/en/docs/v1.4/install/kubernetes/talos-bootstrap.md index 297d6974..a3a60014 100644 --- a/content/en/docs/v1.4/install/kubernetes/talos-bootstrap.md +++ b/content/en/docs/v1.4/install/kubernetes/talos-bootstrap.md @@ -102,6 +102,10 @@ talos-bootstrap --help - 10.96.0.0/16 ``` + {{% alert title="Update Talos to v1.13.6 or newer (CVE-2026-53359)" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both are fixed in the kernel, and Talos v1.13.6 is the first release that carries both fixes — it ships Linux 6.18.38. If the image tag above resolves to an earlier release, set it to `v1.13.6` or newer. Nested virtualization stays enabled: the kernel fix removes the bug itself, so workloads that rely on nested virtualization keep working. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: ```yaml diff --git a/content/en/docs/v1.4/install/kubernetes/talosctl.md b/content/en/docs/v1.4/install/kubernetes/talosctl.md index 1461d23b..5fb792e7 100644 --- a/content/en/docs/v1.4/install/kubernetes/talosctl.md +++ b/content/en/docs/v1.4/install/kubernetes/talosctl.md @@ -126,6 +126,10 @@ Discovered open port 50000/tcp on 192.168.123.13 - 10.96.0.0/16 ``` + {{% alert title="Update Talos to v1.13.6 or newer (CVE-2026-53359)" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both are fixed in the kernel, and Talos v1.13.6 is the first release that carries both fixes — it ships Linux 6.18.38. If the image tag above resolves to an earlier release, set it to `v1.13.6` or newer. Nested virtualization stays enabled: the kernel fix removes the bug itself, so workloads that rely on nested virtualization keep working. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: Note that VIP address is used for `machine.network.interfaces[0].vip.ip`: diff --git a/content/en/docs/v1.5/install/kubernetes/talos-bootstrap.md b/content/en/docs/v1.5/install/kubernetes/talos-bootstrap.md index da3ae158..c7ea2b7e 100644 --- a/content/en/docs/v1.5/install/kubernetes/talos-bootstrap.md +++ b/content/en/docs/v1.5/install/kubernetes/talos-bootstrap.md @@ -102,6 +102,10 @@ talos-bootstrap --help - 10.96.0.0/16 ``` + {{% alert title="Update Talos to v1.13.6 or newer (CVE-2026-53359)" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both are fixed in the kernel, and Talos v1.13.6 is the first release that carries both fixes — it ships Linux 6.18.38. If the image tag above resolves to an earlier release, set it to `v1.13.6` or newer. Nested virtualization stays enabled: the kernel fix removes the bug itself, so workloads that rely on nested virtualization keep working. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: ```yaml diff --git a/content/en/docs/v1.5/install/kubernetes/talosctl.md b/content/en/docs/v1.5/install/kubernetes/talosctl.md index 046bd12b..27c60d86 100644 --- a/content/en/docs/v1.5/install/kubernetes/talosctl.md +++ b/content/en/docs/v1.5/install/kubernetes/talosctl.md @@ -126,6 +126,10 @@ Discovered open port 50000/tcp on 192.168.123.13 - 10.96.0.0/16 ``` + {{% alert title="Update Talos to v1.13.6 or newer (CVE-2026-53359)" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both are fixed in the kernel, and Talos v1.13.6 is the first release that carries both fixes — it ships Linux 6.18.38. If the image tag above resolves to an earlier release, set it to `v1.13.6` or newer. Nested virtualization stays enabled: the kernel fix removes the bug itself, so workloads that rely on nested virtualization keep working. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: Note that VIP address is used for `machine.network.interfaces[0].vip.ip`: From ebd8f091e09ee294c52549f9cb63569c4f4414bd Mon Sep 17 00:00:00 2001 From: Aleksei Sviridkin Date: Thu, 9 Jul 2026 16:17:54 +0300 Subject: [PATCH 3/4] docs: state CVE-2026-53359 exposure where the Talos line has no kernel fix Talos v1.13.6 is the first release carrying both kernel fixes. These docs versions install from the 1.10, 1.11 or 1.12 lines, whose newest releases ship Linux 6.12.63, 6.12.62 and 6.18.35, while the fixes landed in 6.12.95 and 6.18.38. Say so, and name the only complete answer: move to a release that installs from the 1.13 line, then pin the image tag at v1.13.6 or newer. The pre-1.13 pages hardcode a 1.10 image tag while the release itself installs from a later line, so their note names no single line. For readers who cannot upgrade, disabling KVM nested virtualization is still the one available mitigation, so keep it, and separate the ways it goes wrong, because they do not fail alike. On Talos 1.12 and newer a config carrying install.extraKernelArgs is rejected outright unless install.grubUseUKICmdline is false, and talosctl gen config writes that field as true -- Talos says so. On systemd-boot, which a fresh UEFI install of Talos 1.10 or newer uses, the kernel command line lives inside the UKI, and the arguments are accepted and then ignored with nothing reported at all. Point the reader at /proc/cmdline rather than at an assumption. Signed-off-by: Aleksei Sviridkin --- content/en/docs/v0/install/kubernetes/talos-bootstrap.md | 6 ++++++ content/en/docs/v0/install/kubernetes/talosctl.md | 6 ++++++ content/en/docs/v1.0/install/kubernetes/talos-bootstrap.md | 6 ++++++ content/en/docs/v1.0/install/kubernetes/talosctl.md | 6 ++++++ content/en/docs/v1.1/install/kubernetes/talos-bootstrap.md | 6 ++++++ content/en/docs/v1.1/install/kubernetes/talosctl.md | 6 ++++++ content/en/docs/v1.2/install/kubernetes/talos-bootstrap.md | 6 ++++++ content/en/docs/v1.2/install/kubernetes/talosctl.md | 6 ++++++ content/en/docs/v1.3/install/kubernetes/talos-bootstrap.md | 6 ++++++ content/en/docs/v1.3/install/kubernetes/talosctl.md | 6 ++++++ 10 files changed, 60 insertions(+) diff --git a/content/en/docs/v0/install/kubernetes/talos-bootstrap.md b/content/en/docs/v0/install/kubernetes/talos-bootstrap.md index 267e61b4..d1262537 100644 --- a/content/en/docs/v0/install/kubernetes/talos-bootstrap.md +++ b/content/en/docs/v0/install/kubernetes/talos-bootstrap.md @@ -106,6 +106,12 @@ talos-bootstrap --help - 10.96.0.0/16 ``` + {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer. + +If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: ```yaml diff --git a/content/en/docs/v0/install/kubernetes/talosctl.md b/content/en/docs/v0/install/kubernetes/talosctl.md index 32a6dbf8..c15026a9 100644 --- a/content/en/docs/v0/install/kubernetes/talosctl.md +++ b/content/en/docs/v0/install/kubernetes/talosctl.md @@ -130,6 +130,12 @@ Discovered open port 50000/tcp on 192.168.123.13 - 10.96.0.0/16 ``` + {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer. + +If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: Note that VIP address is used for `machine.network.interfaces[0].vip.ip`: diff --git a/content/en/docs/v1.0/install/kubernetes/talos-bootstrap.md b/content/en/docs/v1.0/install/kubernetes/talos-bootstrap.md index 479fe9bc..d2ac062d 100644 --- a/content/en/docs/v1.0/install/kubernetes/talos-bootstrap.md +++ b/content/en/docs/v1.0/install/kubernetes/talos-bootstrap.md @@ -102,6 +102,12 @@ talos-bootstrap --help - 10.96.0.0/16 ``` + {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer. + +If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: ```yaml diff --git a/content/en/docs/v1.0/install/kubernetes/talosctl.md b/content/en/docs/v1.0/install/kubernetes/talosctl.md index 4675df1e..de64af19 100644 --- a/content/en/docs/v1.0/install/kubernetes/talosctl.md +++ b/content/en/docs/v1.0/install/kubernetes/talosctl.md @@ -126,6 +126,12 @@ Discovered open port 50000/tcp on 192.168.123.13 - 10.96.0.0/16 ``` + {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer. + +If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: Note that VIP address is used for `machine.network.interfaces[0].vip.ip`: diff --git a/content/en/docs/v1.1/install/kubernetes/talos-bootstrap.md b/content/en/docs/v1.1/install/kubernetes/talos-bootstrap.md index b380163f..c99b25ca 100644 --- a/content/en/docs/v1.1/install/kubernetes/talos-bootstrap.md +++ b/content/en/docs/v1.1/install/kubernetes/talos-bootstrap.md @@ -102,6 +102,12 @@ talos-bootstrap --help - 10.96.0.0/16 ``` + {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer. + +If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: ```yaml diff --git a/content/en/docs/v1.1/install/kubernetes/talosctl.md b/content/en/docs/v1.1/install/kubernetes/talosctl.md index 3cf1b41a..64a1c4c1 100644 --- a/content/en/docs/v1.1/install/kubernetes/talosctl.md +++ b/content/en/docs/v1.1/install/kubernetes/talosctl.md @@ -126,6 +126,12 @@ Discovered open port 50000/tcp on 192.168.123.13 - 10.96.0.0/16 ``` + {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer. + +If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: Note that VIP address is used for `machine.network.interfaces[0].vip.ip`: diff --git a/content/en/docs/v1.2/install/kubernetes/talos-bootstrap.md b/content/en/docs/v1.2/install/kubernetes/talos-bootstrap.md index 19272544..84a1e6be 100644 --- a/content/en/docs/v1.2/install/kubernetes/talos-bootstrap.md +++ b/content/en/docs/v1.2/install/kubernetes/talos-bootstrap.md @@ -102,6 +102,12 @@ talos-bootstrap --help - 10.96.0.0/16 ``` + {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer. + +If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: ```yaml diff --git a/content/en/docs/v1.2/install/kubernetes/talosctl.md b/content/en/docs/v1.2/install/kubernetes/talosctl.md index 0f451543..588011e2 100644 --- a/content/en/docs/v1.2/install/kubernetes/talosctl.md +++ b/content/en/docs/v1.2/install/kubernetes/talosctl.md @@ -126,6 +126,12 @@ Discovered open port 50000/tcp on 192.168.123.13 - 10.96.0.0/16 ``` + {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer. + +If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: Note that VIP address is used for `machine.network.interfaces[0].vip.ip`: diff --git a/content/en/docs/v1.3/install/kubernetes/talos-bootstrap.md b/content/en/docs/v1.3/install/kubernetes/talos-bootstrap.md index bc7b4743..9cda610a 100644 --- a/content/en/docs/v1.3/install/kubernetes/talos-bootstrap.md +++ b/content/en/docs/v1.3/install/kubernetes/talos-bootstrap.md @@ -102,6 +102,12 @@ talos-bootstrap --help - 10.96.0.0/16 ``` + {{% alert title="No Talos 1.12 release fixes CVE-2026-53359" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and no Talos 1.12 release carries the one for CVE-2026-53359: the newest, v1.12.9, ships Linux 6.18.35, while that fix landed in 6.18.38. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer. + +If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: ```yaml diff --git a/content/en/docs/v1.3/install/kubernetes/talosctl.md b/content/en/docs/v1.3/install/kubernetes/talosctl.md index c3782f42..e0c50131 100644 --- a/content/en/docs/v1.3/install/kubernetes/talosctl.md +++ b/content/en/docs/v1.3/install/kubernetes/talosctl.md @@ -126,6 +126,12 @@ Discovered open port 50000/tcp on 192.168.123.13 - 10.96.0.0/16 ``` + {{% alert title="No Talos 1.12 release fixes CVE-2026-53359" color="warning" %}} +[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and no Talos 1.12 release carries the one for CVE-2026-53359: the newest, v1.12.9, ships Linux 6.18.35, while that fix landed in 6.18.38. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer. + +If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took. + {{% /alert %}} + 1. Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes: Note that VIP address is used for `machine.network.interfaces[0].vip.ip`: From 8a8458767f4020b99d8dc0c7c2dc3e9f282c5696 Mon Sep 17 00:00:00 2001 From: Aleksei Sviridkin Date: Thu, 9 Jul 2026 19:51:18 +0300 Subject: [PATCH 4/4] blog: retract the CVE-2026-53359 nested-virtualization mitigation Talos v1.13.6 shipped on 2026-07-09 with Linux 6.18.38, the first kernel carrying the fixes for both CVE-2026-53359 and its sibling CVE-2026-46113. The advisory was written while no fixed Talos release existed, so it recommended disabling KVM nested virtualization and stated that Cozystack VMs do not need the feature. Both claims are now wrong: the bug is fixed in the kernel, and taking nested virtualization away from workloads that rely on it buys nothing. Lead with an update note, so a reader who acted on the first version learns the recommendation changed rather than finding a silently rewritten page. Say which Talos lines carry the fix and which never will, recommend the upgrade, and keep disabling nested virtualization only as a stop-gap for clusters that cannot upgrade yet. Non-Talos hosts get a fix path too -- their distribution's kernel update -- named without a version, because which stable series carry both patches has not been established here and a security advisory is no place to guess. Correct the stop-gap's caveats, which conflated two unlike failures. Omitting grubUseUKICmdline: false on Talos 1.12 and newer does not quietly drop the kernel arguments -- Talos rejects the config outright, and says so. The quiet failure is systemd-boot, where the command line lives inside the UKI and the arguments are accepted and then ignored with nothing reported; point the reader at /proc/cmdline instead of at an assumption. Drop the automation section: it advertised skills that prescribe and verify a mitigation this advisory no longer recommends. Signed-off-by: Aleksei Sviridkin --- .../index.md | 49 +++++++++++-------- 1 file changed, 29 insertions(+), 20 deletions(-) diff --git a/content/en/blog/2026-07-07-security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/index.md b/content/en/blog/2026-07-07-security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/index.md index 0c2a400a..8cf36add 100644 --- a/content/en/blog/2026-07-07-security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/index.md +++ b/content/en/blog/2026-07-07-security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/index.md @@ -3,7 +3,7 @@ title: "Security Advisory — CVE-2026-53359 (\"Januscape\"): KVM Guest-to-Host slug: security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape date: 2026-07-08 author: "Cozystack Team" -description: "CVE-2026-53359 (\"Januscape\") is a KVM guest-to-host escape affecting all current Talos kernels. Cozystack clusters that run VMs or tenant Kubernetes should disable nested virtualization now." +description: "CVE-2026-53359 (\"Januscape\") is a KVM guest-to-host escape. It is fixed in the kernel: Talos v1.13.6 ships Linux 6.18.38, which carries the patches for this and the related CVE-2026-46113. Upgrade — nested virtualization stays available." images: - "cve-2026-53359-banner.png" article_types: @@ -15,13 +15,17 @@ topics: {{< figure src="cve-2026-53359-banner.png" alt="Security advisory banner — CVE-2026-53359 Januscape KVM guest-to-host escape" width="720" >}} -**Severity:** High for clusters running virtualization. **Status:** No fixed Talos release yet — mitigation required now. +**Update, 2026-07-09.** Talos v1.13.6 has shipped with the fixed kernel. This advisory originally recommended disabling KVM nested virtualization, because at the time no fixed Talos release existed. That recommendation is superseded: upgrade to Talos v1.13.6 or newer and keep nested virtualization enabled. Disabling it remains a stop-gap for clusters that cannot upgrade yet. + +**Severity:** High for clusters running virtualization. **Status:** Fixed in Talos v1.13.6 (Linux 6.18.38), released 2026-07-09. ## What happened On 2026-07-06 a Linux kernel vulnerability, **CVE-2026-53359** ("Januscape"), was publicly disclosed together with a working exploit. It is a use-after-free in the KVM/x86 shadow MMU that lets a **guest VM break out to its host** (the cluster node) or crash the node's kernel. It affects both Intel and AMD CPUs and has been latent in the kernel since 2010. -The upstream fix shipped in stable kernels (6.18.38, 6.12.95, 6.6.144, 6.1.177, 7.1.3) on 2026-07-04, but **Talos Linux has not yet released an image with the fixed kernel.** Every current Talos version still runs a vulnerable kernel. +The upstream fix shipped in stable kernels (6.18.38, 6.12.95, 6.6.144, 6.1.177, 7.1.3) on 2026-07-04. **Talos v1.13.6**, released on 2026-07-09, is the first Talos release to carry it. + +CVE-2026-53359 has a sibling: **CVE-2026-46113**, the same class of use-after-free in the same code path, fixed by a separate upstream patch. A kernel is only fully fixed once it carries both — in the 6.18 series that means 6.18.38 or newer (CVE-2026-46113 landed in 6.18.30), in the 6.12 series 6.12.95 or newer (it landed in 6.12.88). No release on the Talos 1.10, 1.11 or 1.12 lines carries both: the newest of each ships Linux 6.12.63, 6.12.62 and 6.18.35 respectively, and there is no fixed release planned for those lines. ## Who is affected @@ -36,9 +40,19 @@ The exploit needs two things a tenant already has: root inside their own VM, and KubeVirt's sandboxing (unprivileged containers, seccomp, SELinux) does **not** stop this — the bug is in the host kernel and is reached through the normal KVM interface every VM must use. -## Recommended mitigation: disable nested virtualization +## Recommended fix: upgrade Talos + +Upgrade nodes to **Talos v1.13.6** or newer. The bug is fixed in the kernel, so nested virtualization stays enabled and workloads that rely on it keep working. + +Only the 1.13 line has a fixed release. A cluster on Talos 1.10, 1.11 or 1.12 has to move to the 1.13 line to reach the fix; for Cozystack clusters that means upgrading to a release that installs from it. -Cozystack VMs do not need nested virtualization. Disabling it removes the attack surface entirely, regardless of kernel version. +Hosts that do not run Talos need a kernel carrying both patches — take your distribution's kernel update. + +**Warning: upgrading reboots the node.** Roll it out **one node at a time**, waiting for each node to become `Ready` (and for etcd quorum to recover on control-plane nodes) before moving to the next. + +## If you cannot upgrade yet: disable nested virtualization + +The published exploit reaches the bug through nested virtualization exposed to the guest. Disabling it closes that entry point. This is a stop-gap, not a fix — the kernel bug is still there — and it takes the feature away from any workload that needs it. ### Talos (most clusters) @@ -47,15 +61,20 @@ Add to your Talos machine config, under `machine.install`: ```yaml machine: install: - # Talos >= 1.12 only: pin grubUseUKICmdline false so the args are applied - # (otherwise they are silently ignored on UEFI/UKI systems). + # Talos >= 1.12 only: `talosctl gen config` writes this as true, and Talos + # refuses a config that carries both it and extraKernelArgs. The field does + # not exist before 1.12, and it has no effect on systemd-boot nodes. grubUseUKICmdline: false extraKernelArgs: - kvm_intel.nested=0 - kvm_amd.nested=0 ``` -Both lines are safe on Intel and AMD — the one that does not match your CPU is ignored. On Talos **older than 1.12** the `grubUseUKICmdline` field does not exist and `extraKernelArgs` is ignored on UEFI/UKI nodes; there the args must be baked into the boot image via Image Factory. +Both lines are safe on Intel and AMD — the one that does not match your CPU is ignored. + +Two caveats, and they fail differently. On Talos 1.12 and newer, omitting `grubUseUKICmdline: false` does not quietly drop the arguments — Talos rejects the whole config with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. Before 1.12 the field does not exist and is not needed. + +**The second caveat is the quiet one.** These arguments only take effect on GRUB-booted nodes. A fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image; there Talos accepts the arguments and then ignores them, reporting nothing, and `grubUseUKICmdline` does not help because there is no GRUB. Clusters upgraded into 1.10 keep their existing GRUB bootloader and are unaffected. On systemd-boot nodes the arguments have to be baked into the boot assets via Image Factory or Imager. After applying either way, confirm on the node with `cat /proc/cmdline` rather than assuming it took. **Apply it in two steps — `talm apply`, then `talm upgrade`.** First push the updated machine config to the node, then re-run the Talos installer so the kernel arguments are written into the boot configuration (a plain `talm apply` alone does not rewrite the boot config). You can upgrade to the *same* Talos version you are already on — the point is to re-run the installer with the new arguments: @@ -67,29 +86,19 @@ talm apply -f nodes/.yaml talm upgrade -f nodes/.yaml ``` -**Warning: this reboots the node.** Roll it out **one node at a time**, waiting for each node to become `Ready` (and for etcd quorum to recover on control-plane nodes) before moving to the next. +**Warning: `talm upgrade` reboots the node.** Roll it out one node at a time, as above. ### Generic Linux hosts (non-Talos) Create `/etc/modprobe.d/cozystack-kvm-nested.conf`: -``` +```text options kvm_intel nested=0 options kvm_amd nested=0 ``` Then reboot the node (or reload the `kvm` module) for it to take effect. -## Automation - -We have updated our Cozystack Claude Code skills to prescribe and verify this mitigation during bootstrap and upgrades, so the setting is placed under `machine.install` and persists across future Talos upgrades: [cozystack/ccp#17](https://github.com/cozystack/ccp/pull/17). - -You can use the `cozystack:talos-bootstrap` and `cozystack:cluster-upgrade` skills to apply and verify the change automatically. - -## After a fixed Talos ships - -Once Talos releases an image with the patched kernel (6.18.38 or newer), upgrade normally. You may keep nested virtualization disabled as a hardening measure, or re-enable it (remove the two arguments) if a specific workload requires it. We will notify you when a fixed Talos release is available. - ## Join the community * GitHub: [cozystack/cozystack](https://github.com/cozystack/cozystack)