GhostLock (CVE-2026-43499): Linux kernel LPE and container escape analysis
GhostLock is a Linux kernel use-after-free in futex priority inheritance. Patch and verification guidance for operators running containers, virtual machines, and CI jobs.
What operators need to fix
GhostLock, tracked as CVE-2026-43499, is a Linux kernel use-after-free in the rtmutex priority-inheritance path. The affected code can leave a waiter's pi_blocked_on field pointing at a freed stack object after a proxy-lock rollback. The National Vulnerability Database lists it as CVSS 7.8 High with a local attack vector, low complexity, low privileges required, and no user interaction.
Patched kernels have shipped for the major downstreams: AlmaLinux 8, 9, and 10 in their production repositories, CloudLinux 7, 7h, 8, 9, and 10 in the stable channel (2026-07-22) with a KernelCare livepatch (2026-07-31), and Red Hat expediting RHEL fixes under security bulletin RHSB-2026-010 (which tracks CVE-2026-43499 and CVE-2026-53166 together). Install your distribution's fixed kernel and reboot into it. Do not decide from the build date alone. Check your distro's advisory or kernel package changelog for CVE-2026-43499, and compare the running version against the vendor's fixed-version boundary rather than the changelog text.
Why containers do not remove the kernel risk
Containers share the host kernel. Nebula Security's public research describes a full exploit chain that starts from a low-privileged process, reaches root, and can cross a container boundary on affected systems. The vulnerability is in the host kernel, so changing Docker, Kubernetes, or Proxmox settings does not patch the bug.
Namespaces, cgroups, seccomp, AppArmor, and SELinux reduce exploitability but do not isolate the kernel: a reachable local privilege escalation from inside a container is a host escape. The risk depends on who can execute code in a container, the host kernel version, and whether the kernel has the fix. Shared CI runners and multi-user container hosts deserve the shortest patch window because they routinely execute code from less-trusted sources.
The kernel bug
The issue is in remove_waiter(). On a normal locking path, the task performing cleanup is the same task that owns the waiter record. The proxy-lock rollback path breaks that assumption. It can clean up on behalf of a different sleeping task, but the old code operated on current instead of waiter-task.
The NVD description and the upstream fix state that this mismatch can leave the waiter task's pi_blocked_on state uncleared and create a dangling pointer. The upstream fix uses the waiter's task for the affected operations.
Affected versions and fixes
Nebula Security traces the bug to Linux 2.6.39. NVD records affected Linux releases beginning with 2.6.39 and lists fixed stable versions for the maintained series: 6.1.175, 6.6.140, 6.12.86, 6.18.27, 7.0.4, and Linux 7.1. Distribution kernels often backport the fix, so the upstream version number alone is not sufficient for a vendor kernel.
The primary upstream fix is 3bfdc63936dd. A follow-up change (74e144274af3), tracked separately as CVE-2026-53166, was reverted upstream after a regression and is not a second required GhostLock fix. Check the current vendor advisory for the final package you install.
Patch and verify
Inventory every Linux host that runs containers, virtual machines, or self-hosted CI jobs. Install the current security kernel from the distribution or platform vendor. Reboot each host and confirm the running kernel with uname -r. Then match that package to the vendor's CVE-2026-43499 advisory or changelog.
A temporary seccomp rule that blocks priority-inheritance futex operations can reduce exposure in a container, but it can also break workloads that use those operations. Treat it as a short-term control, not a replacement for the kernel update.
Two kernel options make exploitation harder without fixing the bug: RANDOMIZE_KSTACK_OFFSET turns the exploit's deterministic stack-reuse step into a roughly 1/32 guess, and STATIC_USERMODE_HELPER closes the specific DirtyMode pivot, though the same idea generalizes to other predictable kernel data. Treat both as hardening, not remediation — the patched kernel is the fix.
Detection
There is no reliable remote signature for an attempt: the trigger is ordinary threading syscalls that any local process can make. Detection means knowing what untrusted code is allowed to run on the host, and watching the kernel for behavior no legitimate workload should produce.
Patch state
Track the running kernel (uname -r) against your vendor's fixed-version boundary for CVE-2026-43499 as a standing inventory item, not only during a CVE response window. Compare the running version against the vendor's boundary; a changelog grep for the CVE id alone can miss a fix that a vendor build names by upstream commit.
Host behavior on an unpatched host
The useful signals are untrusted local code executing — new shell accounts, CI jobs, container workloads, low-trust plugin installs — plus unexpected kernel-side behavior: unusual kernel modules, anomalous process trees, and privilege transitions no job should make. The kernel-stack use-after-free itself leaves no stable userland artifact, so pair behavioral signals with patch-state tracking rather than expecting a reliable signature.
Prioritize patching shared/multi-tenant machines, cloud servers, containers, and CI runners first. Those hosts combine the trigger (untrusted local code) with the impact (every other workload on the host).
Related
Two adjacent escape paths, on the same host-escape theme:
Januscape (CVE-2026-53359): KVM Host Escape Vulnerability for Proxmox Operators — the same host-escape theme one layer up, at the KVM hypervisor.
Lab note: three runc flaws chain into a container escape to host root — the runc/procfs side of container escape (that post is still a draft in Ghost and may 404 until it is published).
References
Nebula Security: IonStack part II, GhostLock
TuxCare: distribution and mitigation notes
Red Hat, RHSB-2026-010: Locking Subsystem Privilege Escalation (GhostLock)
AlmaLinux, GhostLock (CVE-2026-43499) kernel privilege escalation: patch released
CloudLinux, GhostLock local root exploit: kernel update for CloudLinux
Updated 2026-09-04: patched kernels are now available for AlmaLinux 8/9/10 (production repositories) and CloudLinux 7–10 (stable channel, 22/07/26; KernelCare livepatch 31/07/26); Red Hat RHEL fixes are being expedited under RHSB-2026-010. Added: the patch-status detail above, a detection section, related-escape writeups, and vendor patch references. The kernel-bug and exploit-mechanics sections are unchanged.