Researchers at Nebula Security have disclosed CVE-2026-43499, nicknamed “GhostLock” — a use-after-free in the Linux kernel’s futex priority-inheritance (PI) code that lets any unprivileged local user escalate to root in roughly five seconds. The bug has shipped in mainline since Linux 2.6.39, released in May 2011, meaning it has been present in essentially every mainstream distribution kernel for fifteen years. A public proof-of-concept is now circulating, and the same primitive that grants root also breaks out of Docker and Kubernetes containers, making this a priority patch for any multi-tenant Linux host.

What’s broken

The bug lives in the kernel’s requeue-PI futex path — the mechanism that lets a thread waiting on one priority-inheritance futex be moved onto a different one, used by glibc’s condition-variable implementation under contention. A cleanup routine in that path assumes the thread invoking it owns the futex-wait object being torn down. Requeue-PI operations can violate that assumption: the cleanup can end up operating on the currently executing task’s state instead of the actual waiter’s, leaving stale priority-inheritance bookkeeping behind and a pointer dangling into freed kernel memory.

An attacker who can win the resulting race gets a use-after-free on kernel stack/heap memory reachable from entirely ordinary threading calls — no special capabilities, no unusual kernel config beyond CONFIG_FUTEX_PI (enabled by default nearly everywhere), and no network access required. Nebula’s exploit, submitted through Google’s kernelCTF program and awarded $92,337, reaches 97% reliability turning the UAF into a full root shell in about five seconds, and their testing confirms the same primitive escapes container namespaces, since the corrupted kernel state isn’t scoped per-container.

Fixing it required two upstream commits: 3bfdc63936dd, the primary fix, and a necessary follow-up, 74e144274af3, which was significant enough to be tracked as a separate CVE, CVE-2026-53166. Both are required for a complete fix — a kernel that only picks up the first commit is still exploitable.

Affected versions

  • Vulnerable: Linux kernel 2.6.39 (May 2011) through the last version before the upstream fix landed in 7.1. That spans essentially every LTS branch in production today — 5.10, 5.15, 6.1, 6.6, 6.12, and later.
  • Requirement: CONFIG_FUTEX_PI enabled, which is the default build configuration for virtually every mainstream distribution kernel.
  • Not vulnerable: kernels that have picked up both 3bfdc63936dd and 74e144274af3.

Distribution status as of this week:

  • Ubuntu shipped kernel fixes across USN-8488-1, USN-8489-1, USN-8488-2, and USN-8507-1 in the July 1–6 update cycle.
  • RHEL/CloudLinux: CloudLinux 9 is fixed from kernel-5.14.0-716.el9 onward; Red Hat lists RHEL kernels as affected pending backport in their advisory.
  • Debian: fixed in Debian 13 kernel 6.12.86-1 and later.
  • SUSE and Amazon Linux have published their own CVE tracking entries; check your vendor’s advisory for the specific backport version before assuming you’re covered.

Why it’s worse than a typical local-root bug

Most kernel LPEs need a specific syscall path, an optional module, or unusual privileges to reach. GhostLock needs none of that — the vulnerable code triggers from routine glibc condition-variable contention, meaning any process capable of spawning threads under load can reach it. That makes it directly relevant to:

  1. Shared hosting and CI runners. Any environment where untrusted or semi-trusted code runs as a non-root local user — CI/CD build agents, shared app servers, PaaS tenants — is a direct root-escalation target.
  2. Container and Kubernetes hosts. Because the corruption happens in shared host kernel memory rather than anything namespace-scoped, a process inside an unprivileged container that triggers this race escalates to root on the shared node kernel, not just inside its own container. This is the fourth major 2026 Linux kernel LPE with a documented container-escape path, following Copy Fail, Bad Epoll, and Dirty Frag.
  3. No workaround. CONFIG_FUTEX_PI cannot be disabled without breaking glibc’s threading primitives across the entire userspace stack — this isn’t a bug you can seccomp or blacklist your way around. Patching is the only mitigation.

What to do now

  1. Patch immediately. Pull the kernel build for your distribution that includes both 3bfdc63936dd and 74e144274af3 (tracked as CVE-2026-53166), and reboot — this is memory corruption with no partial-mitigation posture.
  2. Check your distro’s advisory directly rather than assuming a generic “July kernel update” covers it: Ubuntu (USN-8488-1/8489-1/8488-2/8507-1), Red Hat/CloudLinux, Debian 13 (6.12.86-1+), and SUSE have each published separate CVE-2026-43499 tracking pages with their own backport timelines.
  3. Container and Kubernetes fleets: treat node-level kernel patching as urgent regardless of container image hygiene — this bug escapes the container boundary entirely and no application-layer or image-scanning control mitigates it. Wait for or force your managed Kubernetes provider’s node-image refresh (GKE/COS, EKS, AKS) and drain-and-replace affected pools.
  4. No live-patch coverage across the board. KernelCare has published a patch entry for this CVE; if you rely on live patching, confirm your vendor has shipped and applied it rather than assuming coverage.
  5. Public exploit is circulating — this is not a theoretical bug. Any unpatched host with local or CI-agent access should be treated as already at risk.

Why this one matters

GhostLock is the latest in a run of 2026 Linux kernel local-root disclosures — Copy Fail, Dirty Frag, Bad Epoll, and now this — that share a pattern: multi-year-old regressions in core, non-optional kernel subsystems, discovered and weaponized through Google’s kernelCTF bounty program, each with a documented container-escape path. What sets GhostLock apart is reach and age: fifteen years in the wild, reachable from ordinary threading calls rather than an obscure syscall, and no configuration knob to turn it off. If you operate any shared Linux infrastructure — CI runners, container hosts, multi-tenant VMs — this goes to the front of the patch queue.

References