feat(blog): add CVE-2026-43499 (GhostLock) exposure assessment

content/en/blog/2026-07-14-cve-2026-43499-ghostlock-cozystack-exposure-assessment/index.md

@@ -0,0 +1,69 @@
+---
+title: "CVE-2026-43499 (GhostLock): Cozystack Exposure Assessment"
+slug: cve-2026-43499-ghostlock-cozystack-exposure-assessment
+date: 2026-07-14
+author: "Andrei Kvapil"
+description: "CVE-2026-43499 (GhostLock) is a Linux kernel local privilege escalation. Cozystack is not exposed by design, and the fix is the same Talos v1.13.6 kernel upgrade."
+images:
+  - "ghostlock-cozystack-assessment.png"
+article_types:
+  - news
+  - talos
+topics:
+  - security
+  - talos
+  - kubevirt
+  - platform
+
+---
+
+![Security Advisory: CVE-2026-43499 (GhostLock) — Cozystack Exposure Assessment](ghostlock-cozystack-assessment.png)
+
+Third 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.
+
+**TL;DR:** [CVE-2026-43499 ("GhostLock")](https://nvd.nist.gov/vuln/detail/CVE-2026-43499) is a Linux kernel local privilege escalation. By the design of Cozystack, we currently see no viable attack path for a tenant to reach the affected host kernel surface. We still recommend the fix — and it is the **same Talos v1.13.6 upgrade** that closes [Januscape (CVE-2026-53359) and CVE-2026-46113](/blog/2026/07/fixing-cve-2026-53359-januscape-talos-linux/). One move to v1.13.6 closes all three.
+
+## Vulnerability overview
+
+On July 7, 2026, a critical Linux kernel local privilege escalation — **CVE-2026-43499** ("GhostLock") — 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** — an unprivileged local process reaching root on the host kernel.
+
+The 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**.
+
+## Confirmed not affected
+
+GhostLock 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.
+
+- **Managed 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 — a futex sequence issued inside a guest reaches the guest kernel, not the host.
+- **Managed 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.
+- **No arbitrary tenant code on the management cluster.** Cozystack exposes only the managed services we provide — there is no surface on which a tenant runs arbitrary native code in a container on a management node.
+
+By 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.
+
+## Recommended action — same as Januscape: upgrade the kernel
+
+The vulnerability is confirmed in current Talos Linux releases, and any future regression in the isolation above could re-expose it — so we recommend applying the kernel fix regardless.
+
+GhostLock 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 — one move to v1.13.6 closes all three.
+
+- **Already upgraded to v1.13.6 for Januscape? You are protected — no further action needed.**
+- **Not 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.
+
+The full step-by-step upgrade is in our [Januscape fix runbook](/blog/2026/07/fixing-cve-2026-53359-januscape-talos-linux/).
+
+If you cannot upgrade immediately, `kernel.randomize_kstack_offset=1` (via `machine.sysctls`) reduces the exploit's reliability as a defense-in-depth measure — not a substitute for the fix.
+
+We will update this advisory as fixed releases and further mitigations are confirmed.
+
+## References
+
+- [CVE-2026-43499 (GhostLock) — NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-43499)
+- [Fixing CVE-2026-53359 (Januscape) and CVE-2026-46113 on Talos Linux](/blog/2026/07/fixing-cve-2026-53359-januscape-talos-linux/)
+- [Talos Image Factory](https://factory.talos.dev)
+
+### Join the community
+
+- Telegram [group](https://t.me/cozystack)
+- Slack [group](https://kubernetes.slack.com/archives/C06L3CPRVN1) (Get invite at [https://slack.kubernetes.io](https://slack.kubernetes.io))
+- [Community Meeting Calendar](https://calendar.google.com/calendar?cid=ZTQzZDIxZTVjOWI0NWE5NWYyOGM1ZDY0OWMyY2IxZTFmNDMzZTJlNjUzYjU2ZGJiZGE3NGNhMzA2ZjBkMGY2OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t)