{"vulnerability": "CVE-2026-4611", "sightings": [{"uuid": "17ecb261-27b6-499a-87ea-e49639f63114", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-4611", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3mhr7eifcwy2p", "content": "", "creation_timestamp": "2026-03-23T23:24:09.740535Z"}, {"uuid": "90a8a011-7d60-4196-b437-3772791cb036", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46116", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/redhat-linux-kernel-multiple-vulnerabilities_20260803", "content": "", "creation_timestamp": "2026-08-03T10:16:58.711987Z"}, {"uuid": "e3a22788-6e3c-4018-a8db-2a6375474938", "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/redhat-linux-kernel-multiple-vulnerabilities_20260803", "content": "", "creation_timestamp": "2026-08-03T10:16:20.903074Z"}, {"uuid": "3bcec5d5-88ad-4056-92e7-bb2edf9ad9c7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46112", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/ubuntu-linux-kernel-multiple-vulnerabilities_20260803", "content": "", "creation_timestamp": "2026-08-03T07:44:50.227186Z"}, {"uuid": "3daa6151-a94d-4af3-a2f7-eacac3ffc581", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-46114", "type": "seen", "source": "https://infosec.exchange/users/vuldb/statuses/116655797964744274", "content": "Attention, elevated activities detected targeting Linux Kernel (CVE-2026-46114) https://vuldb.com/vuln/366603/cti", "creation_timestamp": "2026-05-29T03:43:34.732591Z"}, {"uuid": "000844f4-cd43-41db-ad01-d1b1c1b1d5f0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46116", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/debian-linux-kernel-multiple-vulnerabilities_20260806", "content": "", "creation_timestamp": "2026-08-06T04:45:37.589978Z"}, {"uuid": "d39f05ab-efc2-4401-962f-1044d72a7ce1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46117", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/debian-linux-kernel-multiple-vulnerabilities_20260630", "content": "", "creation_timestamp": "2026-07-01T02:34:44.861802Z"}, {"uuid": "821c7fa1-d850-4113-93ca-a46ffae3aac8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46115", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/ubuntu-linux-kernel-multiple-vulnerabilities_20260702", "content": "", "creation_timestamp": "2026-07-02T06:52:14.969356Z"}, {"uuid": "74c1eda6-1c70-48ab-889b-51ee3dcd5c41", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46119", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/ubuntu-linux-kernel-multiple-vulnerabilities_20260702", "content": "", "creation_timestamp": "2026-07-02T06:52:17.143084Z"}, {"uuid": "1f135036-5063-415d-ad22-93c5d73eda6d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46119", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/suse-linux-kernel-multiple-vulnerabilities_20260702", "content": "", "creation_timestamp": "2026-07-02T07:17:48.517412Z"}, {"uuid": "8635b831-199f-4e65-b163-4a61d677572a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46110", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/debian-linux-kernel-multiple-vulnerabilities_20260706", "content": "", "creation_timestamp": "2026-07-06T06:19:17.912469Z"}, {"uuid": "c224e43e-7342-4cbf-838c-bcf432d8f829", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46112", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/debian-linux-kernel-multiple-vulnerabilities_20260706", "content": "", "creation_timestamp": "2026-07-06T06:19:20.292055Z"}, {"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": "bbc5b130-d57a-425d-a4b1-5851f35b426a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46116", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/debian-linux-kernel-multiple-vulnerabilities_20260706", "content": "", "creation_timestamp": "2026-07-06T06:19:26.768681Z"}, {"uuid": "9af261e5-4411-4263-8f4e-4c517233ce16", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46119", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/debian-linux-kernel-multiple-vulnerabilities_20260706", "content": "", "creation_timestamp": "2026-07-06T06:19:30.229184Z"}, {"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": "e715234e-4908-4be5-8724-fac7a5ce85bc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46116", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/redhat-linux-kernel-multiple-vulnerabilities_20260702", "content": "", "creation_timestamp": "2026-07-09T00:45:26.021867Z"}, {"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": "a9aadf34-9fed-432f-96ea-c8590bfa0bc3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46110", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/suse-linux-kernel-multiple-vulnerabilities_20260702", "content": "", "creation_timestamp": "2026-07-09T01:19:27.179632Z"}, {"uuid": "d731776f-b7cd-4073-96f6-8eb244d2e7f8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46111", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/suse-linux-kernel-multiple-vulnerabilities_20260702", "content": "", "creation_timestamp": "2026-07-09T01:19:29.460398Z"}, {"uuid": "bc214fb9-0573-42b3-98eb-e2305633c077", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-46114", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/suse-linux-kernel-multiple-vulnerabilities_20260702", "content": "", "creation_timestamp": "2026-07-09T01:19:34.176650Z"}, {"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"}, {"uuid": "96d4ae25-09b1-406f-9210-d6c52f206c74", "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/mherrera782-rgb/259992523a664f7f49b2364767207041", "content": "---\ntitle: \"Thelio Mira Multi-Tenant Client VM Hosting - Phase 1 Pablo Independent Research\"\ntask_slug: \"THELIO-MULTITENANT-RD-P1\"\nauthor: \"Senor Pablo\"\ncreated_at_utc: \"2026-09-12T16:13:26Z\"\nphase: \"Joint R&D Rigor Phase 1\"\nstatus: \"independent findings, not final policy\"\n---\n\n# Thelio Mira Multi-Tenant Client VM Hosting - Phase 1 Pablo Independent Research\n\n## 0. Boundary\n\nThis is an independent Phase 1 research packet for the standing policy question:\n\n> Thelio Mira multi-tenant client-VM hosting: durable isolation-management architecture and policy.\n\nIt is not implementation authority. It does not authorize VM creation, runtime/config changes, service changes, bridge changes, source activation, credential movement, client onboarding, or production hosting. Later phases should compare this with CF and Fable-5 findings before hardening into a Matthis-facing policy.\n\nMy evidence should be treated as current as of 2026-09-12. Where vendor docs were scraped live, I cite them directly. Where search summaries were used, I label them as lower confidence.\n\n## 1. Bottom Line\n\nThe strongest near-term policy is not \"install one VM per client and call it isolated.\" It is a small multi-tenant hypervisor operating policy with admission gates, patch gates, per-tenant network/storage/control-plane separation, and explicit residual-risk disclosure.\n\nFor Thelio Mira, the practical strongest path is:\n\n1. Continue with KVM/libvirt only if it is wrapped in a durable host admission checklist and per-tenant build template.\n2. Require host-native kernel/CVE verification before any client VM is admitted.\n3. Put every client VM on a separate virtual network or bridge, never shared `virbr0`.\n4. Disable or remove convenience channels: guest Tailscale, shared folders, qemu guest agent, clipboard, virtiofs/9p, ballooning, KSM, broad serial/log sharing.\n5. Treat the host/hypervisor as trusted by design, because Ryzen 9 9950X3D-class consumer hardware does not provide AMD SEV-SNP confidential VM isolation.\n6. Use a \"cloud-API-only\" rule for OpenClaw clones and client agents unless a separate GPU/isolation design is authorized.\n7. Adopt patch automation and monitoring as a gate, not a best-effort hygiene note.\n\nProxmox VE is worth serious consideration if Matthis wants Thelio Mira to become a recurring client-VM host rather than a one-off workstation running a few VMs. Proxmox adds a real management plane, roles, pools, VM firewalling, backup semantics, and SDN concepts that raw libvirt will otherwise require Pablo/CF to recreate by convention. OpenStack is too heavy for a single workstation-scale host. Firecracker/crosvm are worth watching for future narrow Linux agent sandboxes, but they are not a clean replacement for ordinary full-OS client VMs this week.\n\n## 2. YT Corpus Preflight\n\n```yaml\nYT_CORPUS_PREFLIGHT:\n  query_terms:\n    - multi-tenant\n    - hypervisor\n    - KVM\n    - VM escape\n    - Proxmox\n    - OpenStack\n    - Firecracker\n    - crosvm\n    - Livepatch\n    - libvirt\n  corpus_last_ingest:\n    date: 2026-07-15\n    generated_at_utc: \"2026-07-16T03:00:54.640118+00:00\"\n    source_path: \"docs/youtube/nightly-catchup/2026-07-15/youtube-catchup-manifest.json\"\n  result: NO_MATCH\n  matches: []\n  unsurfaced_match_count: 0\n  caveat: \"Corpus items are curated creator content - prior context, not verified evidence.\"\n```\n\n## 3. Phase 1 Brainstorm Evidence\n\n```yaml\nphase_1_brainstorm_evidence:\n  brainstorm_required: true\n  brainstorm_protocol_completion: true\n  brainstorm_mode: full\n  task_class: \"Hardware / Infra + Protocol / Governance\"\n  method_lenses:\n    - decision_matrix\n    - assumption_storming\n    - pre_mortem\n    - adversarial_security_review\n  divergent_generation:\n    competing_threads:\n      - \"Raw KVM/libvirt with strict Pablo-authored policy templates and verification gates.\"\n      - \"Proxmox VE as small-ops virtualization management plane.\"\n      - \"OpenStack/Nova/Neutron as cloud-like tenant model.\"\n      - \"Firecracker/crosvm microVMs for future lightweight Linux-only agent sandboxes.\"\n      - \"Separate physical hardware for higher-assurance client isolation.\"\n      - \"Hosted cloud confidential-compute alternative for clients needing stronger hardware-backed isolation.\"\n    alternative_framings:\n      - \"This is less a clone-install problem than a tenant admission-control problem.\"\n      - \"VM isolation is an operating discipline, not a one-time topology.\"\n      - \"Cloud providers accept residual hypervisor risk, but they pair it with fleet patching, detection, hardware choices, and abuse controls.\"\n    failure_modes_or_tensions:\n      - \"A VM exists but is attached to shared NAT/default L2, leaking hostnames or exposing broadcasts.\"\n      - \"Patch automation installs a fixed kernel package but the host has not rebooted into it.\"\n      - \"Guest convenience features silently create host-guest channels.\"\n      - \"A client interprets 'isolated' as host-admin-proof confidential computing.\"\n      - \"An agent clone is isolated at filesystem level but shares Discord bridge, model key, or tailnet visibility.\"\n      - \"A single-host design accumulates too much manual state to audit under time pressure.\"\n  known_unknowns:\n    open_questions:\n      - \"What exact Ubuntu release/kernel/package stream will Thelio Mira run as the KVM host?\"\n      - \"Will Matthis give any client direct VM console or SSH access, or are all client VMs agent-operated only?\"\n      - \"Will client data require contractual security language beyond Matthis-owned-risk disclosure?\"\n      - \"Will Thelio Mira remain a workstation with Sunshine/desktop workload, or become a dedicated client-VM host?\"\n    visibility_limits:\n      - \"Current local shell is WSL and cannot certify Thelio Mira bare-metal kernel, libvirt state, CPU topology, KSM, AppArmor, or VM configuration.\"\n      - \"No CF/Fable-5 independent packet was read before authoring this Phase 1 artifact.\"\n  convergence_boundary:\n    conclusions_deferred: true\n    cross_analysis_or_design_deferred_to_later_phase: true\n```\n\n## 4. Research Threads\n\n### Thread A - Threat Model And Honest Isolation Language\n\nClient VMs on one host can be strongly separated from each other by KVM, per-VM QEMU processes, mandatory access control, virtual network separation, per-disk file permissions, resource quotas, and patch discipline. They cannot be honestly described as \"totally isolated\" in the physical or hypervisor-compromise sense.\n\nThe honest language should be:\n\n> Thelio Mira provides hardened logical VM isolation on Matthis-owned shared hardware. The host/hypervisor remains a trusted component. A host compromise, hypervisor escape, firmware compromise, malicious administrator action, or severe hardware side channel can break tenant isolation.\n\nThis is similar in category to public-cloud multi-tenancy, but not equal in assurance. AWS/GCP/Azure pair shared-host virtualization with dedicated security teams, custom hardware/firmware chains, confidential computing SKUs, fleet-wide telemetry, live migration, automated patch rollouts, and formal incident processes. Thelio Mira can borrow operating patterns, not claim cloud-provider-grade guarantees.\n\nPolicy implication: every client admission should classify whether \"host owner can technically access or disrupt the VM\" is acceptable. If not, Thelio Mira is the wrong substrate; use dedicated hardware or cloud confidential compute.\n\n### Thread B - KVM/Libvirt Baseline\n\nRaw KVM/libvirt is a viable substrate only if we make implicit host controls explicit. The required baseline is:\n\n- one tenant/client per VM unless Matthis explicitly accepts same-client grouping\n- no shared libvirt `default` network for unrelated clients\n- one virtual network/bridge per tenant, with no L2 sharing between tenants\n- no guest VPN/tailnet membership by default\n- no host-shared folders, virtiofs, 9p, shared clipboard, broad virtio-serial, qemu guest agent, or SPICE convenience channels\n- AppArmor/sVirt confinement enabled and verified per QEMU process\n- QEMU running unprivileged under the distro libvirt user model\n- KSM disabled and masked\n- memory ballooning disabled for client VMs\n- fixed memory reservations; avoid overcommit for client workloads\n- CPU topology policy: avoid cross-tenant SMT sibling sharing, or disable SMT/core-schedule if threat model requires it\n- nested virtualization disabled unless a client workload explicitly requires it and Matthis accepts increased risk\n- `/dev/kvm` limited to trusted virtualization users/groups, not world-writable\n- separate VM images, backup targets, serial logs, cloud-init seed ISOs, and metadata\n- separate secrets, model-provider keys/projects, Discord bot identities, and bridge scope\n\nLibvirt can do most of this, but it does not force Pablo/CF to remember it. That is the danger. If raw libvirt stays the approach, Thelio Mira needs a \"client VM admission checklist\" plus machine-readable config audit script before first client launch.\n\n### Thread C - Proxmox VE As Small-Ops Management Plane\n\nProxmox VE is the most plausible alternative to hand-managed libvirt for a single-node or small-node client VM host. It provides a web/API management plane over KVM/QEMU, storage, backup, firewall, permissions, and SDN concepts. The attractive part is not magic isolation; it is that tenancy controls become visible objects: users/groups, pools, network definitions, VM firewall flags, backup jobs, and storage allocation.\n\nLikely advantages:\n\n- resource pools and ACLs reduce accidental cross-tenant operator access\n- SDN/VLAN/VXLAN/VNet concepts make per-tenant network separation less ad hoc\n- VM firewall and anti-spoofing settings are first-class operational controls\n- snapshots/backups are native operational concepts\n- easier audit/readback for \"which VM belongs to which tenant\"\n- better fit if Matthis expects recurring VM lifecycle work\n\nLikely costs:\n\n- changes the host operating model and may conflict with Thelio Mira workstation/desktop-stack goals\n- adds a large management plane that itself needs patching and access control\n- may require reinstall/migration or careful coexistence decisions\n- web UI exposure becomes a new attack surface if not tailnet/localhost/admin-only\n- still not confidential computing; hypervisor remains trusted\n\nPreliminary position: adopt/watch. Proxmox is worth a decision gate if Thelio Mira is truly becoming a standing client-VM host. It is too big to casually install as a side effect of clone provisioning.\n\n### Thread D - OpenStack Nova/Neutron\n\nOpenStack has the right conceptual model for multi-tenant VM hosting: projects, RBAC, Nova placement, Neutron networks/security groups, host aggregates, provider network RBAC, anti-spoofing, and cloud-style operational separation. It also has the wrong scale for this immediate problem.\n\nOpenStack makes sense when the operational goal is a cloud with multiple compute nodes, API-driven tenant self-service, live migration, image services, block/object storage, quotas, and mature operator staffing. Thelio Mira is a single workstation-class host with desktop-stack work landing in parallel. Running OpenStack to protect one or a few local client VMs likely creates more failure modes than it removes.\n\nPreliminary position: skip for Thelio Mira Phase 1/2. Borrow concepts: projects/tenants, network RBAC, security groups, host aggregate ideas, anti-spoofing, and explicit compute placement. Do not deploy OpenStack.\n\n### Thread E - Firecracker / Crosvm / MicroVMs\n\nFirecracker is built for secure, multi-tenant function/container-style services. Its own docs say it is purpose-built for secure multi-tenant container and function services, uses KVM, has a minimal device model, supports very low VM overhead, includes a jailer, applies seccomp filters, cgroups, namespaces, and rate limiting, and expects host-level network filtering. It is an alternative to general-purpose QEMU for narrow Linux workloads.\n\nImportant source facts:\n\n- Firecracker is \"purpose-built for creating and managing secure, multi-tenant container and function-based services.\"\n- It exposes only a minimal device model and is written in Rust.\n- Production use should start Firecracker via the `jailer`.\n- It explicitly says it does not perform network filtering and guest egress should be filtered at the host level.\n- Each Firecracker process encapsulates one microVM.\n\nThis is attractive for future OpenClaw worker/agent sandboxes if we can standardize immutable images and API-driven boot. It is not a drop-in replacement for full client Ubuntu desktops or arbitrary VMs. It also adds a custom image-building and orchestration problem.\n\nCrosvm has similar minimal-VMM appeal, but Firecracker has stronger production proof in serverless/container multi-tenancy and clearer public docs for jailer/seccomp/resource limits.\n\nPreliminary position: watch/pilot later for narrow Linux agent runtimes. Do not block current Thelio Mira client VM policy on adopting microVMs.\n\n### Thread F - Patch Management And VM Escape Reality\n\nThe Januscape/CVE pair makes the guest-to-host risk concrete. Ubuntu tracks CVE-2026-53359 as a High priority, CVSS 8.8, \"guest to host escape in KVM,\" fixed for Ubuntu 26.04 generic `linux` at `7.0.0-29.29` and Ubuntu 24.04 generic `linux` at `6.8.0-137.137`; patch detail references `81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb`. Ubuntu tracks CVE-2026-46113 as CVSS 8.8 for KVM shadow paging UAF, fixed for Ubuntu 26.04 generic `linux` at `7.0.0-28.28` and 24.04 generic `linux` at `6.8.0-136.136`, with patch `0cb2af2ea66ad8ff195c156ea690f11216285bdf`.\n\nGoogle's kvmCTF rules are also useful calibration: Google pays up to $250,000 for full KVM VM escapes, $100,000 for arbitrary memory writes, $50,000 for arbitrary memory reads, and $20,000 for host DoS. That is not compliance theater. It is a live research market around exactly this boundary.\n\nThe policy should separate three patch states:\n\n- `SAFE_TO_ADMIT`: running kernel and installed kernel packages meet current CVE floor; no reboot-required mismatch; libvirt/qemu package status current.\n- `PATCHED_ON_DISK_ONLY`: fixed kernel package installed but host has not rebooted; no new client VM admission.\n- `UNKNOWN_OR_VULNERABLE`: cannot prove fixed version; no new client VM admission.\n\nCanonical Livepatch should be considered an exposure-window reducer, not a reboot substitute. Ubuntu's Livepatch page says it patches high/critical kernel vulnerabilities while the system runs and reduces unplanned work; it also says Livepatch is not a replacement for upgrade and reboot. Ubuntu unattended-upgrades applies security updates automatically and has explicit reboot and service restart behavior, including default `Automatic-Reboot \"false\"`.\n\nPreliminary patch policy:\n\n- enable security unattended-upgrades, but no automatic host reboot\n- enable Ubuntu Pro Livepatch if license/accounting is acceptable\n- monitor livepatch status, `/var/run/reboot-required`, installed-vs-running kernel, qemu/libvirt pending restarts, and Ubuntu CVE status for KVM packages\n- set a hard maximum exposure SLA for High/Critical KVM guest-host CVEs\n- require scheduled reboot maintenance when Livepatch cannot cover a CVE or when fixed packages are only installed on disk\n\n## 5. Tooling And Platform Candidate Scan\n\n### Raw KVM/libvirt\n\nLicense/maturity: mature OSS, standard Linux virtualization stack.\n\nIntegration cost: low near-term, high policy burden.\n\nAdopt/watch/skip: adopt only with policy wrapper and audit script.\n\nWhy: best near-term compatibility; weak default ergonomics for recurring multi-tenant operation.\n\n### Proxmox VE\n\nLicense/maturity: mature OSS/commercial support ecosystem.\n\nIntegration cost: medium to high depending on whether Thelio Mira can become Proxmox-first rather than Ubuntu-desktop-first.\n\nAdopt/watch/skip: watch/decision-gate; possible adopt if Matthis wants recurring VM hosting.\n\nWhy: turns tenant resources, backups, firewalling, pools, and permissions into visible managed objects.\n\n### OpenStack\n\nLicense/maturity: mature OSS cloud platform.\n\nIntegration cost: very high.\n\nAdopt/watch/skip: skip for single-host Thelio Mira; borrow concepts only.\n\nWhy: right abstraction at wrong scale.\n\n### Firecracker\n\nLicense/maturity: Apache 2.0, production lineage via AWS Lambda/Fargate class services.\n\nIntegration cost: medium/high because it requires image, network, jailer, API, and lifecycle tooling.\n\nAdopt/watch/skip: watch/pilot later for narrow Linux API-agent sandboxes.\n\nWhy: excellent attack-surface story for small Linux microVMs; not a general VM/desktop replacement.\n\n### Crosvm\n\nLicense/maturity: mature in ChromiumOS/ChromeOS virtualization lineage.\n\nIntegration cost: medium/high, fewer obvious small-ops recipes than libvirt/Proxmox.\n\nAdopt/watch/skip: watch.\n\nWhy: useful reference point for minimal VMM design; Firecracker looks more directly relevant for multi-tenant agent workloads.\n\n### Ubuntu Pro Livepatch\n\nLicense/maturity: Canonical product, mature.\n\nIntegration cost: low if Ubuntu Pro account/token available.\n\nAdopt/watch/skip: adopt candidate for hypervisor host, subject to Matthis account/license decision.\n\nWhy: reduces urgent reboot pressure for high/critical kernel CVEs but does not replace reboots.\n\n### Canonical Landscape\n\nLicense/maturity: Canonical systems management.\n\nIntegration cost: medium.\n\nAdopt/watch/skip: watch unless Thelio Mira grows into several hosts.\n\nWhy: overkill for one host but useful if patch/compliance reporting becomes a client-facing obligation.\n\n## 6. Phase 1 Toolkit Audit\n\n### Toolkit Inventory\n\n```yaml\ntoolkit_inventory:\n  local_shell_inventory: partial\n  reason: \"Current Pablo shell is WSL; cannot certify Mira bare-metal host.\"\n  web_search: strong\n  firecrawl_scrape: strong\n  pablo_joint_rd_rigor_skill: strong\n  clone_provisioning_skill: strong\n  clone_service_safety_skill: strong\n  current_libvirt_host_access: missing\n  host_native_kernel_readback: missing\n  host_native_libvirt_readback: missing\n  vm_config_audit_script: missing\n  per_tenant_manifest_template: missing\n  patch_sla_monitor: missing\n  CVE_floor_registry: missing\n  backup_restore_test_fixture: missing\n```\n\n### Gap / Cost Analysis\n\n```yaml\ngap_cost_analysis:\n  - gap: \"No host-native Mira evidence surface in current Pablo shell.\"\n    cost: \"Low if Matthis/CF can run read-only host commands; high if access path remains unclear.\"\n    risk_if_open: \"False security claims and wrong sizing/gating.\"\n  - gap: \"No durable client VM admission checklist.\"\n    cost: \"Medium documentation plus command-readback schema.\"\n    risk_if_open: \"Ad hoc VM creation misses a bridge, shared folder, qga, KSM, or patch gate.\"\n  - gap: \"No automated libvirt/domain/network audit.\"\n    cost: \"Medium script development and test fixtures.\"\n    risk_if_open: \"Config drift silently weakens tenant isolation.\"\n  - gap: \"No KVM CVE floor monitor.\"\n    cost: \"Medium; combine Ubuntu CVE pages/package versions/reboot-required checks.\"\n    risk_if_open: \"Host admits clients while vulnerable or patched-on-disk-only.\"\n  - gap: \"No client-facing residual-risk disclosure template.\"\n    cost: \"Low/medium; needs Matthis/legal/commercial judgment.\"\n    risk_if_open: \"Overpromising isolation.\"\n  - gap: \"No backup/restore drill policy per tenant.\"\n    cost: \"Medium ongoing operational burden.\"\n    risk_if_open: \"Backups exist but cannot be safely restored or are cross-tenant contaminated.\"\n```\n\n### Needed Enablement\n\n```yaml\nneeded_enablement:\n  - \"THELIO_HOST_READBACK.v1: host-native kernel, CPU topology, RAM, disk, GPU, firmware, KVM/libvirt, AppArmor, KSM, nested virt, qemu package versions.\"\n  - \"CLIENT_VM_ADMISSION_CHECKLIST.v1: pre-admission gates, build constraints, forbidden features, disclosure state, operator signoff.\"\n  - \"CLIENT_VM_CONFIG_AUDIT.v1: read-only script comparing libvirt XML/network definitions against policy.\"\n  - \"KVM_CVE_PATCH_GATE.v1: Ubuntu CVE fixed-version registry plus running/installed kernel comparison.\"\n  - \"TENANT_NETWORK_TEMPLATE.v1: separate libvirt network or bridge per tenant, no default virbr0.\"\n  - \"TENANT_BACKUP_RESTORE_POLICY.v1: separate destinations, encryption ownership, restore drills.\"\n  - \"BRIDGE_SCOPE_AUDIT.v1: ensure Discord/OpenClaw bridges cannot cross tenant boundaries.\"\n```\n\n### Prioritized Gap Registry\n\n```yaml\nprioritized_gap_registry:\n  - rank: 1\n    gap: \"Host-native Mira readback missing.\"\n    owner: \"CF/Matthis/Pablo when proper surface exists\"\n    next_gate: \"CF-AUTH for host-native read-only verification\"\n  - rank: 2\n    gap: \"KVM CVE patch gate missing.\"\n    owner: \"Pablo proposal, CF/Matthis approval\"\n    next_gate: \"Joint Phase 3/4 synthesis\"\n  - rank: 3\n    gap: \"Client VM admission checklist missing.\"\n    owner: \"Pablo/CF co-authored policy\"\n    next_gate: \"Joint Phase 5 Matthis decision\"\n  - rank: 4\n    gap: \"Read-only libvirt isolation audit script missing.\"\n    owner: \"Pablo after CF-AUTH\"\n    next_gate: \"Implementation authorization\"\n  - rank: 5\n    gap: \"Client residual-risk disclosure language missing.\"\n    owner: \"Matthis/CF with Pablo technical input\"\n    next_gate: \"Matthis business/legal judgment\"\n```\n\n## 7. Source Review Forced Adjacency Scan\n\n```yaml\nsource_review_forced_adjacency_scan:\n  methodology:\n    finding: \"Treat VM hosting as admission-control and continuous assurance, not one-time build.\"\n    staged_action: \"Create durable checklist and audit artifact after joint synthesis.\"\n  tooling:\n    finding: \"Raw libvirt needs wrappers; Proxmox may reduce drift for recurring hosting; Firecracker is future-specialized.\"\n    staged_action: \"Decision gate: raw libvirt now vs Proxmox migration/pilot.\"\n  governance:\n    finding: \"Client admission requires explicit residual-risk language and patch gate.\"\n    staged_action: \"Matthis/CF decide client-facing language before onboarding.\"\n  market_structure:\n    finding: \"Cloud providers accept shared-hypervisor risk but compensate with hardware, telemetry, and dedicated security ops.\"\n    staged_action: \"Do not imply cloud-equivalent assurance on Thelio Mira.\"\n  source_discovery:\n    finding: \"Useful ongoing sources: Ubuntu CVE tracker/USNs, kernel stable releases, libvirt/qemu advisories, Google kvmCTF/security-research, Proxmox advisories.\"\n    staged_action: \"Build CVE source list into patch monitor if authorized.\"\n  watch_project_cross_reference:\n    finding: \"Impacts Thelio desktop-stack VM, OpenClaw clone provisioning, Discord bridge scoping, model routing, backup/Drive relay boundaries.\"\n    staged_action: \"Cross-analysis must include these surfaces.\"\n  sme_domain_routing:\n    finding: \"Security SME review should gate implementation.\"\n    staged_action: \"Require Security SME before first client VM if policy becomes operational.\"\n```\n\n## 8. Joint R&D Adjacency Map\n\n```yaml\njoint_rd_adjacency_map_v0:\n  triggered: true\n  trigger_basis: security_governance\n  independent_author: Pablo\n  adjacency_candidates:\n    - surface_name: \"clone-provisioning/SKILL.md\"\n      surface_type: skill\n      direct_effect: \"Future clone readiness must distinguish Matthis-owned clone VMs from client tenant VMs.\"\n      risk_if_missed: \"A client-facing clone could inherit Matthis-owned Option C assumptions.\"\n      confidence: high\n    - surface_name: \"clone-spawning-service-safety/SKILL.md\"\n      surface_type: skill\n      direct_effect: \"Clone services must remain tenant-scoped and never mutate canonical gateway/bridge units.\"\n      risk_if_missed: \"One clone service change could affect another tenant or main Pablo.\"\n      confidence: high\n    - surface_name: \"Discord bridge / OpenClaw bridge configuration\"\n      surface_type: service\n      direct_effect: \"Bridge scope must be per-clone/per-tenant, not globally subscribed.\"\n      risk_if_missed: \"Messaging stream becomes a cross-tenant data path.\"\n      confidence: high\n    - surface_name: \"Thelio desktop-stack runbook\"\n      surface_type: doc\n      direct_effect: \"Desktop VM GPU/Sunshine choices compete with client VM isolation and resource policy.\"\n      risk_if_missed: \"GPU passthrough or remote-access convenience features weaken tenant boundary.\"\n      confidence: medium\n    - surface_name: \"CF_STATUS.md / CF_SESSION_MEMORY task gates\"\n      surface_type: governance\n      direct_effect: \"Client VM admission needs explicit patch/readback gates before build CF-AUTH.\"\n      risk_if_missed: \"Queue movement could look like implementation approval before host safety is proven.\"\n      confidence: high\n  exchanged_at_phase_2: false\n  raw_findings_reference: \"pending_gist\"\n  forbidden_actions:\n    - \"no implementation authority\"\n    - \"no runtime/config/cron/service mutation\"\n    - \"no source activation or scoring/model-feed change\"\n    - \"no portfolio or trading action\"\n```\n\n## 9. Expert In Loop Thread\n\n```yaml\nexpert_in_loop_thread:\n  triggered: true\n  trigger_basis: security\n  reviewed_roles:\n    - Security SME\n    - Authority Reviewer\n  required_gate_role: Security SME\n  implementation_gate: SME_REVIEW_REQUIRED\n  rationale: \"The design affects client data isolation, hypervisor escape risk, host/guest channels, credentials, bridge scoping, and patch gates.\"\n  risk_if_omitted: \"A plausible-looking VM setup could overclaim tenant isolation or miss a known escape/side-channel class.\"\n  forbidden_actions:\n    - \"no implementation before required gate\"\n    - \"no runtime/config/cron/service mutation\"\n    - \"no source activation or scoring/model-feed change\"\n    - \"no portfolio or trading action\"\n```\n\n## 10. Candidate Policy Skeleton For Later Phases\n\nThis skeleton is included as Phase 1 raw material, not a final recommendation.\n\n### Client VM Admission Gate\n\nEach client VM requires:\n\n- client classification: Matthis-owned, internal, client-facing, regulated/sensitive, or high-risk untrusted\n- explicit acceptance of shared-host residual risk\n- host-native kernel and package readback\n- current KVM CVE floor pass\n- no reboot-required mismatch for kernel/qemu/libvirt\n- AppArmor/sVirt pass\n- KSM disabled/masked\n- nested virtualization disabled\n- `/dev/kvm` permissions restricted\n- per-tenant network/bridge pass\n- no default `virbr0` attachment\n- no guest VPN/tailnet unless explicitly justified\n- no qemu guest agent/shared folders/clipboard/virtiofs/9p\n- fixed RAM, no ballooning\n- CPU placement policy pass\n- backup target declared and separated\n- Discord/model/API identity separation where applicable\n\n### Ongoing Assurance\n\nDaily or per-session read-only checks:\n\n- running kernel version\n- installed kernel package candidate\n- reboot-required and reboot-required packages\n- Ubuntu CVE status for KVM/kernel/qemu/libvirt\n- Livepatch status when enabled\n- libvirt VM list and domain XML policy diff\n- network attachment audit\n- KSM state\n- qemu guest agent/channel audit\n- backup freshness\n- failed login/console access log review\n\n### Incident Gate\n\nOn High/Critical KVM guest-to-host CVE:\n\n- freeze new client VM admissions\n- classify running host as patched, patched-on-disk-only, or vulnerable/unknown\n- if livepatch covers it, mark exposure reduced but still schedule reboot if needed\n- if no livepatch or vulnerable running kernel, shut down/suspend client VMs or isolate per Matthis/CF decision\n- document client notification requirement if any client SLA/disclosure requires it\n\n## 11. Recency Check\n\n```yaml\nrecency_check:\n  current_date: \"2026-09-12\"\n  sources:\n    - url: \"https://ubuntu.com/security/CVE-2026-53359\"\n      source_date: \"published 2026-07-04; updated 2026-09-07\"\n      freshness: current\n    - url: \"https://ubuntu.com/security/CVE-2026-46113\"\n      source_date: \"published 2026-05-28; updated 2026-09-07\"\n      freshness: current\n    - url: \"https://ubuntu.com/server/docs/how-to/software/automatic-updates/\"\n      source_date: \"modified 2026-07-15\"\n      freshness: current\n    - url: \"https://ubuntu.com/security/livepatch\"\n      source_date: \"scraped 2026-09-12; page current enough for product posture\"\n      freshness: current\n    - url: \"https://firecracker-microvm.github.io/\"\n      source_date: \"scraped 2026-09-12\"\n      freshness: current\n    - url: \"https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md\"\n      source_date: \"latest visible commit 2026-05-06\"\n      freshness: current\n    - url: \"https://github.com/google/security-research/blob/master/kvmctf/rules.md\"\n      source_date: \"latest visible commit 2026-07-31\"\n      freshness: current\n    - url: \"https://www.amd.com/en/developer/sev.html\"\n      source_date: \"scraped 2026-09-12; page metadata updated 2026-09-08\"\n      freshness: current\n  stale_risk: \"low for cited CVE and vendor product posture; medium for operational advice until validated against Mira host.\"\n```\n\n## 12. What CF Should Challenge\n\n- Whether Proxmox is worth the host-operating-model disruption, or whether raw libvirt plus audit script is sufficient for the next 30 days.\n- Whether \"client-facing\" should always require a client notification/disclosure artifact before admission.\n- Whether no guest Tailscale is too strict for operational recovery.\n- Whether qemu guest agent should be entirely forbidden or allowed in tightly bounded internal-only VMs.\n- Whether memory ballooning and KSM should be globally disabled even for Matthis-owned/non-client VMs to reduce drift.\n- Whether Firecracker deserves an early pilot for OpenClaw clones if they are Linux API-only.\n\n## 13. Silent False Success Modes\n\n- Host has fixed kernel package installed but is still running vulnerable old kernel.\n- VM is on a separate subnet but same L2 bridge/dnsmasq as another tenant.\n- Discord bot token is separate but bridge process subscribes to all channels.\n- VM disk paths are separate but backup job stores all tenant backups in one unsegmented location.\n- AppArmor is installed but libvirt domain profiles are unconfined or permissive.\n- KSM is disabled once but re-enabled after reboot or package/service change.\n- No guest Tailscale is configured, but host-side NAT still allows VM-to-VM routing.\n- qemu guest agent absent at install but later added by template inheritance.\n- CPU pinning exists but ignores SMT sibling topology.\n- Client hears \"isolated VM\" and assumes host-admin-proof confidentiality.\n\n## 14. Sources\n\n- Ubuntu CVE-2026-53359: https://ubuntu.com/security/CVE-2026-53359\n- Ubuntu CVE-2026-46113: https://ubuntu.com/security/CVE-2026-46113\n- Ubuntu automatic updates documentation: https://documentation.ubuntu.com/server/how-to/software/automatic-updates/\n- Ubuntu Livepatch: https://ubuntu.com/security/livepatch\n- Firecracker homepage/docs: https://firecracker-microvm.github.io/\n- Firecracker design doc: https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md\n- Google kvmCTF rules: https://github.com/google/security-research/blob/master/kvmctf/rules.md\n- AMD SEV overview: https://www.amd.com/en/developer/sev.html\n- Proxmox VE administration guide: https://pve.proxmox.com/pve-docs/pve-admin-guide.html\n- OpenStack Security Guide: https://docs.openstack.org/security-guide/\n\n## 15. Phase 1 Closeout\n\n```yaml\nphase_1_closeout:\n  artifact_type: independent_research_packet\n  conclusion_status: preliminary_findings_only\n  recommended_next_phase: \"Phase 2 exchange raw findings; Phase 3 cross-analysis after Drive/Gist relay verification.\"\n  implementation_authority: false\n  runtime_mutation_authority: false\n  client_vm_admission_authority: false\n```\n", "creation_timestamp": "2026-09-12T16:21:16.208081Z"}]}