fix(talos): bump Talos to v1.13.6 (CVE-2026-53359) - #3240
fix(talos): bump Talos to v1.13.6 (CVE-2026-53359)#3240Aleksei Sviridkin (lexfrei) merged 1 commit into
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR bumps the Talos profile version from v1.13.5 to v1.13.6 across six profile YAML files (initramfs, installer, iso, kernel, metal, nocloud). It updates baseInstaller.imageRef and all systemExtensions imageRef entries with new tags and SHA256 digests. ChangesTalos v1.13.6 image profile bump
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
size/M
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request implements a security hardening measure for Talos images to address the 'Januscape' vulnerability (CVE-2026-53359). By baking the necessary kernel arguments directly into the boot assets during the image build process, the changes ensure that nested virtualization is disabled on the host, preventing potential guest-to-host escapes. This approach is necessary because standard machine-config overrides are ineffective for kernel command-line arguments in certain boot configurations. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on Gemini (@gemini-code-assist) comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the Talos profile generation script (hack/gen-profiles.sh) and regenerates the corresponding profile YAML files (installer.yaml, iso.yaml, metal.yaml, and nocloud.yaml) to disable KVM nested virtualization (kvm_intel.nested=0 and kvm_amd.nested=0) as a mitigation for CVE-2026-53359 (Januscape). This customization is applied to all boot-producing profiles while excluding bare kernel and initramfs outputs. There are no review comments, and I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
5364552 to
af11c41
Compare
af11c41 to
8f0e7f0
Compare
github-actions
Bot
added
size/L
Aleksei Sviridkin (lexfrei)
changed the title
IvanHunters
left a comment
IvanHunters
left a comment
There was a problem hiding this comment.
LGTM. Clean security bump to Talos v1.13.6 closing CVE-2026-53359 (and CVE-2026-46113). All 6 profiles regenerated consistently via gen-profiles.sh; extension digests and firmware build coherent. Nested virt correctly left enabled: the fix is in the kernel, disabling the feature would only mask the symptom. No upgrade/fresh-install impact (build-time image generation only).
8f0e7f0 to
b384980
Compare
…workers (#3254) ## What this PR does The in-sandbox Talos image cache added in #3244 is unreachable by the tenant workers it was meant to serve, so it makes the `kubernetes-latest` / `kubernetes-previous` e2e tests fail deterministically instead of relieving the intermittent public-factory flake it targets (#3231). Every branch off current `main` inherits this — for example #3240 has failed its tenant-Kubernetes e2e repeatedly for this reason alone, despite being unrelated (it only touches host boot assets). Root cause: tenant namespaces run under a default-deny Cilium egress installed by the tenant chart. A worker's CDI importer is allowed to reach the outside world (so the public factory works) and kube-dns (so the name resolves), but nothing permits egress to an arbitrary `kube-system` Service. The importer therefore resolves `talos-image-cache.kube-system.svc` yet its TCP connect to the ClusterIP is silently dropped (`dial tcp <clusterip>:80: i/o timeout`), the DataVolume import never starts, the worker VM stays `DataVolumeError`, and no tenant node joins within the 12-minute deadline. #3244's readiness gate never caught this because it probed the server over `localhost` inside the serve Pod, which passes regardless of cross-Pod reachability. Two changes: - Ship a tightly-scoped `CiliumClusterwideNetworkPolicy` that lets importer Pods in `tenant-test` egress to the mirror Pod in `kube-system`. Cilium unions allow rules, so this only adds a hole; scoping it to a namespace that is already default-deny egress means it never flips another namespace's posture, and the mirror Pod needs no ingress rule because no ingress policy selects it. The policy is applied at point-of-use (not with the rest of the mirror manifest, which is applied before Cilium's CRDs exist). - Replace the localhost range-probe with one that faces the exact same network path as a real importer: a throwaway Pod in the tenant namespace, labelled `cdi.kubevirt.io=importer`, that fetches the seeded image from the Service ClusterIP with a Range request and must get a `206`. Tenants are pointed at the mirror only when that end-to-end check passes; otherwise the harness falls back to the public factory. This restores the invariant #3244 intended — the mirror can only help, never make CI worse. Not a retry/timeout bump: it fixes the real network path and adds a genuine reachability gate. ### Screenshots N/A — CI-only change, no user-facing surface. ### Release note ```release-note test(e2e): make the in-sandbox Talos image cache reachable by tenant Kubernetes workers, fixing deterministic kubernetes-* e2e failures (#3231) ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Updated Talos image cache e2e selection to run a tenant-scoped reachability probe to the local mirror and require HTTP byte-range support (`206`) before using it. * If the probe fails or does not confirm byte-range behavior, the flow now reliably falls back to the public Talos image source. * Added CI-only tenant egress controls to allow importer Pods to reach the mirror Service. * **Documentation** * Expanded e2e guidance to clarify the mirror is best-effort and that fallback happens at probe time. * **Tests** * Added a new Bats suite covering manifest splitting, policy wiring, probe overrides, and strict `206` gating/fallback scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Talos v1.13.5 ships Linux 6.18.36, which carries the fix for CVE-2026-46113 but not the one for CVE-2026-53359. The two are related KVM x86 shadow-paging bugs allowing a guest to escape to the host, and both patches are needed for the mitigation to hold. Talos v1.13.6 ships Linux 6.18.38, the first release on the 6.18 stable line that has both. Profiles regenerated with hack/gen-profiles.sh v1.13.6. Alongside the Talos version and the installer reference, this refreshes the pinned system-extension digests: the firmware extensions move from the 20260519 to the 20260622 build, and intel-ucode stays on its 20260512 tag but resolves to a new digest because upstream re-pushed that tag. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Aleksei Sviridkin <f@lex.la>
b384980 to
3e9b560
Compare
Reconciles the talos-image-cache conflicts created when #3254 merged to main: keep the Chainsaw _lib/ port (hack/e2e-chainsaw/_lib/talos-image-cache.sh, a superset of #3254's logic + the node-join diagnose helper), drop the BATS-era hack/e2e-apps/talos-image-cache.sh, and keep the _lib/-path versions of the mirror manifest, install bats, and unit test. Also picks up main's zizmor action-pinning (#3223, unblocks pre-commit/zizmor) and Talos v1.13.6 (#3240). Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
3 participants
What this PR does
Bumps the platform Talos profiles from v1.13.5 to v1.13.6.
CVE-2026-53359 and CVE-2026-46113 are related KVM x86 shadow-paging use-after-free bugs that let a guest escape to the host, and the fix is complete only once both upstream patches (
81ccda30b4e8,0cb2af2ea66a) are applied. On the 6.18 stable line CVE-2026-46113 landed in 6.18.30 and CVE-2026-53359 in 6.18.38. Talos v1.13.5 runs Linux 6.18.36, so it carries only the first of the two. Talos v1.13.6 runs Linux 6.18.38 and carries both.Nested virtualization stays enabled. The bugs are fixed in the kernel, so there is no reason to take the feature away from workloads that rely on it — bumping the kernel is the complete fix.
Profiles are regenerated with
hack/gen-profiles.sh v1.13.6. Alongside the Talos version and the installer reference, this refreshes the pinned system-extension digests: the firmware extensions move from the 20260519 to the 20260622 build, andintel-ucodekeeps its20260512tag but resolves to a new digest because upstream re-pushed that tag as an OCI image index (identical config and layer blobs underneath).References: Talos v1.13.6 release notes (
Linux: 6.18.38)Screenshots
Not applicable, no UI changes.
Release note