{"vulnerability": "CVE-2026-46113", "sightings": [{"uuid": "52e71b79-3a49-43a3-b144-5b39dab966d2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46113", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/debian-linux-kernel-multiple-vulnerabilities_20260706", "content": "", "creation_timestamp": "2026-07-06T06:19:22.613044Z"}, {"uuid": "22d61f3b-83ef-4fce-8a18-f8a18a5d6ab9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-46113", "type": "seen", "source": "https://bsky.app/profile/librecanada.bsky.social/post/3mq2guglwls2o", "content": "TuxCare - Video \n\"Januscape CVE-2026-46113: KVM/x86 Guest-to-Host Escape Explained\" \n\nwww.youtube.com/live/DZgjh_K...\n\n==========================\n#librecanada #linux #opensource", "creation_timestamp": "2026-07-07T10:53:54.142612Z"}, {"uuid": "1d258ee6-c33b-4b6f-bc39-50f840c62f3c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46113", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/suse-linux-kernel-multiple-vulnerabilities_20260702", "content": "", "creation_timestamp": "2026-07-09T01:19:31.720490Z"}, {"uuid": "1e04a64f-200a-4902-96e3-c7c5b775a6bb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-46113", "type": "seen", "source": "https://gist.github.com/lexfrei/4e8e13137f97b60874350ef2ac512f6d", "content": "# Correctly fixing CVE-2026-53359 (Januscape) + CVE-2026-46113 on Talos Linux\n\n## TL;DR\n\nThe config-based mitigation for CVE-2026-53359 that's often recommended \u2014 `machine.install.extraKernelArgs: [kvm_intel.nested=0, kvm_amd.nested=0]` \u2014 **is silently ignored on Talos nodes that boot via systemd-boot / UKI** (bare-metal UEFI is the common case). The kernel command line is baked into the signed UKI and cannot be changed by machine config; `grubUseUKICmdline` only affects GRUB.\n\nThe correct fix is to **upgrade to a Talos build whose kernel already contains the patch** \u2014 Linux **6.18.38**, shipped in **Talos v1.13.6** \u2014 which closes **both** CVEs at the kernel level. Then you don't need to disable nested virtualization at all.\n\n## The two CVEs and their fixed kernels\n\nBoth are KVM x86 shadow-paging use-after-free bugs enabling guest-to-host escape:\n\n| CVE | Fixed in the 6.18.x line |\n| --- | --- |\n| CVE-2026-46113 | 6.18.30 |\n| CVE-2026-53359 (Januscape) | 6.18.38 |\n\nStable kernels are cumulative, so **6.18.38 contains both fixes**. Mapping to Talos:\n\n- Talos **v1.13.5** \u2192 kernel 6.18.36 \u2192 fixes only 46113 (NOT 53359).\n- Talos **v1.13.6** \u2192 kernel 6.18.38 \u2192 fixes **both**.\n\nSo bump to **v1.13.6**, not v1.13.5.\n\n## Why the config mitigation fails on systemd-boot\n\nTalos docs, verbatim: *\"the `.machine.install.extraKernelArgs` field is ignored, as kernel arguments are embedded in the UKI and cannot be modified without upgrading the UKI.\"*\n\n- `kvm_intel`/`kvm_amd` are built into the Talos kernel, so `modprobe.d` does nothing and `/sys/module/kvm_intel/parameters/nested` is `0444` (read-only). `nested=` is settable only via the kernel command line.\n- On systemd-boot the cmdline lives inside the signed UKI, so `extraKernelArgs` are dropped \u2014 Talos even warns `extra kernel arguments are not supported when booting using SDBoot`.\n- `grubUseUKICmdline: false` only helps GRUB nodes. On a systemd-boot node, `talosctl upgrade` with these args leaves `/proc/cmdline` unchanged and nested stays on.\n\nSo on systemd-boot nodes, disabling nested via config is not possible \u2014 but you don't need to. Just run a fixed kernel.\n\n## The fix \u2014 upgrade to Talos v1.13.6\n\nIf your nodes use system extensions (drbd, zfs, firmware, GPU, ucode), build a Talos Image Factory schematic and upgrade to it. Nothing here requires a custom-built image \u2014 Image Factory assembles the stock installer plus the official extensions declaratively.\n\n### 1. Create a schematic with your extensions\n\n```sh\ncat > schematic.yaml <<'YAML'\ncustomization:\n  systemExtensions:\n    officialExtensions:\n      - siderolabs/drbd\n      - siderolabs/zfs\n      - siderolabs/amd-ucode\n      - siderolabs/intel-ucode\n      - siderolabs/amdgpu\n      - siderolabs/i915\n      - siderolabs/bnx2-bnx2x\n      - siderolabs/intel-ice-firmware\n      - siderolabs/qlogic-firmware\nYAML\n\ncurl -sX POST --data-binary @schematic.yaml https://factory.talos.dev/schematics\n# -> {\"id\":\"\"}\n```\n\nTrim the extension list to what your cluster actually uses.\n\n### 2. Upgrade node-by-node\n\n```sh\ntalosctl -n  upgrade \\\n  --image factory.talos.dev/installer/:v1.13.6\n```\n\n`talosctl upgrade` re-runs the installer, rewrites the boot assets and reboots. Roll one node at a time; on control-plane nodes wait for etcd and your CSI/storage to be healthy between nodes. Note: Talos only tests migrations between adjacent minors, so from an old release upgrade sequentially through each minor's latest patch (e.g. 1.10 \u2192 1.11 \u2192 1.12 \u2192 1.13) rather than jumping straight.\n\n### 3. Verify\n\n```sh\ntalosctl -n  version                          # Server: v1.13.6\ntalosctl -n  read /proc/sys/kernel/osrelease  # 6.18.38-talos\ntalosctl -n  get extensions                   # your extensions present\n```\n\n`kvm_intel.nested` may stay `Y` \u2014 that is fine; the vulnerable code path is fixed in the kernel.\n\n## Ready example (Cozystack extension set)\n\nA schematic with the standard Cozystack extension set (drbd, zfs, amd/intel-ucode, amdgpu, i915, bnx2-bnx2x, intel-ice-firmware, qlogic-firmware):\n\n- Schematic ID: `be66fdc8a38c2f517f33cba0a6daa7ab97ff87d51e8ca7d2160e45911ba09cf5`\n- Installer: `factory.talos.dev/installer/be66fdc8a38c2f517f33cba0a6daa7ab97ff87d51e8ca7d2160e45911ba09cf5:v1.13.6`\n\n## References\n\n- CVE-2026-53359 (Januscape): https://nvd.nist.gov/vuln/detail/CVE-2026-53359\n- CVE-2026-46113: https://nvd.nist.gov/vuln/detail/CVE-2026-46113\n- Talos bootloader (GRUB vs systemd-boot, UKI cmdline): https://docs.siderolabs.com/talos/v1.13/platform-specific-installations/bare-metal-platforms/bootloader\n- Talos Image Factory: https://factory.talos.dev\n", "creation_timestamp": "2026-07-09T12:33:33.585564Z"}, {"uuid": "a972783b-ff12-4e4b-b708-05a749643338", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-46113", "type": "seen", "source": "https://t.me/aenix_io/427", "content": "\ud83d\udc7bThird CVE this week, but good news: Cozystack isn't exposed by design and the fix is the same v1.13.6 upgrade you already know. Details below\ud83d\udc47\n\nSecurity Advisory: CVE-2026-43499 (\"GhostLock\") \u2014 Cozystack Exposure Assessment\nOn July 7, 2026, a critical Linux kernel local privilege escalation \u2014 CVE-2026-43499 (\"GhostLock\") \u2014 was disclosed with a working proof-of-concept. It is a stack use-after-free in the kernel real-time mutex (rtmutex) priority-inheritance path, reachable from futex(2): on the proxy-lock rollback taken from futex_requeue(), remove_waiter() clears pi_blocked_on on the wrong task, leaving a dangling pointer to a freed kernel stack frame. Introduced in Linux 2.6.39 (2011), it affects every kernel up to v7.1-rc1, needs only CONFIG_FUTEX_PI=y (no capabilities, no user namespaces), and can be escalated into a container escape \u2014 an unprivileged local process reaching root on the host kernel.\n\nThe upstream fix is commit 3bfdc63936dd, shipped in stable kernels 6.1.175, 6.6.140, 6.12.86, 6.18.27, and 7.0.4.\n\nReference: https://nvd.nist.gov/vuln/detail/CVE-2026-43499\n\nConfirmed not affected\nGhostLock is a local escalation: it presupposes the attacker can already run native code on the host kernel's syscall surface. By design, Cozystack gives tenants no way to do that.\n\nManaged Kubernetes and VirtualMachine services. All tenant workloads execute inside guest virtual machines running on top of unprivileged containers. Tenant code has no direct access to the host kernel syscall surface \u2014 a futex sequence issued inside a guest reaches the guest kernel, not the host.\n\nManaged databases run as non-root, non-superuser users, with no Kubernetes API access and no ability to execute arbitrary code in the server process, so a tenant cannot issue the syscall sequence the exploit requires.\n\nNo arbitrary tenant code on the management cluster. Cozystack exposes only the managed services we provide \u2014 there is no surface on which a tenant runs arbitrary native code in a container on a management node.\nBy the design of Cozystack, we currently do not see any viable attack path that would allow a tenant to reach the host kernel surface affected by this vulnerability.\n\nRecommended action \u2014 same as Januscape: upgrade the kernel\nThe vulnerability is confirmed in current Talos Linux releases, and any future regression in the isolation above could re-expose it \u2014 so we recommend applying the kernel fix regardless.\n\nGhostLock is fixed in Talos Linux v1.13.6 (kernel 6.18.38-talos, newer than the first fixed 6.18.27). This is the same upgrade we recommended for CVE-2026-53359 (\"Januscape\") and CVE-2026-46113 \u2014 one move to v1.13.6 closes all three.\n\nAlready upgraded to v1.13.6 for Januscape? You are protected \u2014 no further action needed.\nNot yet? Follow the same runbook: build an Image Factory installer with your extensions, upgrade node-by-node to v1.13.6, and verify talosctl read /proc/sys/kernel/osrelease shows 6.18.38-talos. Move one node at a time, waiting for etcd quorum and storage health between control-plane nodes.\nIf you cannot upgrade immediately, kernel.randomize_kstack_offset=1 (via machine.sysctls) reduces the exploit's reliability as a defense-in-depth measure \u2014 not a substitute for the fix.\n\nWe will update this advisory as fixed releases and further mitigations are confirmed.", "creation_timestamp": "2026-07-29T12:00:04.400982Z"}, {"uuid": "044ad11f-0b84-4cbb-bbd6-4d39af294a63", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-46113", "type": "seen", "source": "https://t.me/aenix_io/426", "content": "\ud83d\udc8a Fixing CVE-2026-53359 (Januscape) + CVE-2026-46113 on Talos Linux\n\nContext\nCVE-2026-53359 (Januscape) and CVE-2026-46113 are KVM x86 shadow-paging use-after-free bugs that let a guest VM escape to the host. Both are fixed in Linux 6.18.38, which ships in Talos v1.13.6. Upgrading to it closes both at the kernel level \u2014 you do not need to disable nested virtualization.\n\nThe commonly suggested config mitigation:\nmachine.install.extraKernelArgs: [kvm_intel.nested=0, kvm_amd.nested=0] \u2014 is silently ignored on systemd-boot / UKI nodes (the usual bare-metal UEFI case):\n\nkvm_intel/kvm_amd are built into the Talos kernel, so modprobe.d and runtime /sys writes don\u2019t apply (/sys/module/kvm_intel/parameters/nested is 0444); nested= is settable only via the kernel command line.\nOn 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.\n\nSo the fix is a kernel bump, not a config knob.\n\nRunbook\n\n1. Build an Image Factory schematic with your extensions\nIf your nodes use system extensions (drbd, zfs, firmware, GPU, ucode), declare them \u2014 Image Factory assembles the stock installer plus the official extensions, no custom image build required.\n\ncat > schematic.yaml <<'YAML'\ncustomization:\n  systemExtensions:\n    officialExtensions:\n      - siderolabs/drbd\n      - siderolabs/zfs\n      - siderolabs/amd-ucode\n      - siderolabs/intel-ucode\n      - siderolabs/amdgpu\n      - siderolabs/i915\n      - siderolabs/bnx2-bnx2x\n      - siderolabs/intel-ice-firmware\n      - siderolabs/qlogic-firmware\nYAML\n\ncurl -sX POST --data-binary @schematic.yaml https://factory.talos.dev/schematics\n# -> {\"id\":\"\"}\n\nTrim the extension list to what your cluster actually uses.\n\n2. Upgrade node-by-node\n\ntalosctl -n  upgrade \\\n  --image factory.talos.dev/installer/:v1.13.6\n\nRoll 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 \u2014 from an old release, upgrade sequentially through each minor\u2019s latest patch rather than jumping straight.\n\n3. Verify\n\ntalosctl -n  version                          # Server: v1.13.6\ntalosctl -n  read /proc/sys/kernel/osrelease  # 6.18.38-talos\ntalosctl -n  get extensions                   # your extensions present\n\nkvm_intel.nested may stay Y \u2014 that\u2019s expected; the vulnerable path is fixed in the kernel.\n\nReady installer (Cozystack extension set)\n\nStandard Cozystack extensions (drbd, zfs, amd/intel-ucode, amdgpu, i915, bnx2-bnx2x, intel-ice-firmware, qlogic-firmware):\n\nfactory.talos.dev/installer/be66fdc8a38c2f517f33cba0a6daa7ab97ff87d51e8ca7d2160e45911ba09cf5:v1.13.6\n\nReferences:\n\nCVE-2026-53359 (Januscape): \nhttps://nvd.nist.gov/vuln/detail/CVE-2026-53359\nCVE-2026-46113: https://nvd.nist.gov/vuln/detail/CVE-2026-46113\n\nTalos bootloader / UKI cmdline: https://docs.siderolabs.com/talos/v1.13/platform-specific-installations/bare-metal-platforms/bootloader\n\nTalos Image Factory: https://factory.talos.dev", "creation_timestamp": "2026-07-29T12:00:04.505455Z"}, {"uuid": "0a94e3a4-52fb-459c-962c-50ebe8264ebd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-46113", "type": "seen", "source": "https://t.me/aenix_io/426", "content": "\ud83d\udc8a Fixing CVE-2026-53359 (Januscape) + CVE-2026-46113 on Talos Linux\n\nContext\nCVE-2026-53359 (Januscape) and CVE-2026-46113 are KVM x86 shadow-paging use-after-free bugs that let a guest VM escape to the host. Both are fixed in Linux 6.18.38, which ships in Talos v1.13.6. Upgrading to it closes both at the kernel level \u2014 you do not need to disable nested virtualization.\n\nThe commonly suggested config mitigation:\nmachine.install.extraKernelArgs: [kvm_intel.nested=0, kvm_amd.nested=0] \u2014 is silently ignored on systemd-boot / UKI nodes (the usual bare-metal UEFI case):\n\nkvm_intel/kvm_amd are built into the Talos kernel, so modprobe.d and runtime /sys writes don\u2019t apply (/sys/module/kvm_intel/parameters/nested is 0444); nested= is settable only via the kernel command line.\nOn 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.\n\nSo the fix is a kernel bump, not a config knob.\n\nRunbook\n\n1. Build an Image Factory schematic with your extensions\nIf your nodes use system extensions (drbd, zfs, firmware, GPU, ucode), declare them \u2014 Image Factory assembles the stock installer plus the official extensions, no custom image build required.\n\ncat > schematic.yaml <<'YAML'\ncustomization:\n  systemExtensions:\n    officialExtensions:\n      - siderolabs/drbd\n      - siderolabs/zfs\n      - siderolabs/amd-ucode\n      - siderolabs/intel-ucode\n      - siderolabs/amdgpu\n      - siderolabs/i915\n      - siderolabs/bnx2-bnx2x\n      - siderolabs/intel-ice-firmware\n      - siderolabs/qlogic-firmware\nYAML\n\ncurl -sX POST --data-binary @schematic.yaml https://factory.talos.dev/schematics\n# -> {\"id\":\"\"}\n\nTrim the extension list to what your cluster actually uses.\n\n2. Upgrade node-by-node\n\ntalosctl -n  upgrade \\\n  --image factory.talos.dev/installer/:v1.13.6\n\nRoll 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 \u2014 from an old release, upgrade sequentially through each minor\u2019s latest patch rather than jumping straight.\n\n3. Verify\n\ntalosctl -n  version                          # Server: v1.13.6\ntalosctl -n  read /proc/sys/kernel/osrelease  # 6.18.38-talos\ntalosctl -n  get extensions                   # your extensions present\n\nkvm_intel.nested may stay Y \u2014 that\u2019s expected; the vulnerable path is fixed in the kernel.\n\nReady installer (Cozystack extension set)\n\nStandard Cozystack extensions (drbd, zfs, amd/intel-ucode, amdgpu, i915, bnx2-bnx2x, intel-ice-firmware, qlogic-firmware):\n\nfactory.talos.dev/installer/be66fdc8a38c2f517f33cba0a6daa7ab97ff87d51e8ca7d2160e45911ba09cf5:v1.13.6\n\nReferences:\n\nCVE-2026-53359 (Januscape): \nhttps://nvd.nist.gov/vuln/detail/CVE-2026-53359\nCVE-2026-46113: https://nvd.nist.gov/vuln/detail/CVE-2026-46113\n\nTalos bootloader / UKI cmdline: https://docs.siderolabs.com/talos/v1.13/platform-specific-installations/bare-metal-platforms/bootloader\n\nTalos Image Factory: https://factory.talos.dev", "creation_timestamp": "2026-07-30T00:00:31.410517Z"}, {"uuid": "de7ff4bc-1492-4a0e-8585-e242f167b09c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-46113", "type": "seen", "source": "https://t.me/aenix_io/427", "content": "\ud83d\udc7bThird CVE this week, but good news: Cozystack isn't exposed by design and the fix is the same v1.13.6 upgrade you already know. Details below\ud83d\udc47\n\nSecurity Advisory: CVE-2026-43499 (\"GhostLock\") \u2014 Cozystack Exposure Assessment\nOn July 7, 2026, a critical Linux kernel local privilege escalation \u2014 CVE-2026-43499 (\"GhostLock\") \u2014 was disclosed with a working proof-of-concept. It is a stack use-after-free in the kernel real-time mutex (rtmutex) priority-inheritance path, reachable from futex(2): on the proxy-lock rollback taken from futex_requeue(), remove_waiter() clears pi_blocked_on on the wrong task, leaving a dangling pointer to a freed kernel stack frame. Introduced in Linux 2.6.39 (2011), it affects every kernel up to v7.1-rc1, needs only CONFIG_FUTEX_PI=y (no capabilities, no user namespaces), and can be escalated into a container escape \u2014 an unprivileged local process reaching root on the host kernel.\n\nThe upstream fix is commit 3bfdc63936dd, shipped in stable kernels 6.1.175, 6.6.140, 6.12.86, 6.18.27, and 7.0.4.\n\nReference: https://nvd.nist.gov/vuln/detail/CVE-2026-43499\n\nConfirmed not affected\nGhostLock is a local escalation: it presupposes the attacker can already run native code on the host kernel's syscall surface. By design, Cozystack gives tenants no way to do that.\n\nManaged Kubernetes and VirtualMachine services. All tenant workloads execute inside guest virtual machines running on top of unprivileged containers. Tenant code has no direct access to the host kernel syscall surface \u2014 a futex sequence issued inside a guest reaches the guest kernel, not the host.\n\nManaged databases run as non-root, non-superuser users, with no Kubernetes API access and no ability to execute arbitrary code in the server process, so a tenant cannot issue the syscall sequence the exploit requires.\n\nNo arbitrary tenant code on the management cluster. Cozystack exposes only the managed services we provide \u2014 there is no surface on which a tenant runs arbitrary native code in a container on a management node.\nBy the design of Cozystack, we currently do not see any viable attack path that would allow a tenant to reach the host kernel surface affected by this vulnerability.\n\nRecommended action \u2014 same as Januscape: upgrade the kernel\nThe vulnerability is confirmed in current Talos Linux releases, and any future regression in the isolation above could re-expose it \u2014 so we recommend applying the kernel fix regardless.\n\nGhostLock is fixed in Talos Linux v1.13.6 (kernel 6.18.38-talos, newer than the first fixed 6.18.27). This is the same upgrade we recommended for CVE-2026-53359 (\"Januscape\") and CVE-2026-46113 \u2014 one move to v1.13.6 closes all three.\n\nAlready upgraded to v1.13.6 for Januscape? You are protected \u2014 no further action needed.\nNot yet? Follow the same runbook: build an Image Factory installer with your extensions, upgrade node-by-node to v1.13.6, and verify talosctl read /proc/sys/kernel/osrelease shows 6.18.38-talos. Move one node at a time, waiting for etcd quorum and storage health between control-plane nodes.\nIf you cannot upgrade immediately, kernel.randomize_kstack_offset=1 (via machine.sysctls) reduces the exploit's reliability as a defense-in-depth measure \u2014 not a substitute for the fix.\n\nWe will update this advisory as fixed releases and further mitigations are confirmed.", "creation_timestamp": "2026-07-30T00:00:31.970431Z"}]}