GhostLock — rtmutex/futex stack use-after-free

This tracker is no longer updated. Every tracked kernel has shipped the 3bfdc63936dd backport; the only permanent exceptions are covered in prose — RHEL 9 GA kernel-rt (still unfixed per Red Hat), the end-of-support Amazon Linux 2, and Proxmox’s superseded 6.14/6.11 series.

Summary

How the exploitation chain works

GhostLock is a use-after-free of on-stack kernel memory in the real-time mutex (rtmutex) priority-inheritance implementation. rtmutex backs the kernel side of PI futexes: when a thread blocks on a PI futex it allocates an rt_mutex_waiter on its kernel stack, links it into the lock’s waiter tree, and records the blocking relationship in the task’s pi_blocked_on field.

remove_waiter() unwinds that state. It was written for the ordinary case — a task that blocked on its own behalf and now cleans up after itself — so it operates on current: it clears current->pi_blocked_on and walks the PI chain starting from current.

The futex requeue-PI path breaks that assumption. futex_requeue() (with FUTEX_CMP_REQUEUE_PI) moves a waiter from one futex to another and, in doing so, can take the rtmutex on behalf of a different task than the one running. When that operation must be rolled back — the requeue forms a PI deadlock and returns -EDEADLK — the cleanup calls remove_waiter() from the requeuing thread’s context, but the waiter it must unlink belongs to the other task. remove_waiter() dutifully clears pi_blocked_on on current (the requeuer) instead of on waiter->task (the real waiter), and walks the wrong PI chain.

The real waiter’s pi_blocked_on is left pointing at an rt_mutex_waiter that lived in a kernel stack frame which has since unwound and been reused — a dangling stack pointer. A later PI operation dereferences it; because the attacker controls what now occupies that stack slot, the primitive becomes a write of a controlled pointer to a near-arbitrary address — enough to corrupt kernel structures and gain root, or, from inside an unprivileged container, to escape to the host.

Triggering it requires arranging a specific PI deadlock cycle across three futexes so the requeue returns -EDEADLK and takes the buggy rollback path; the PoC does this from an entirely unprivileged process.

The fix, 3bfdc63936dd, makes remove_waiter() operate on waiter->task — the task that actually owns the waiter — instead of current, so the requeue-PI rollback clears pi_blocked_on on the right task and walks the right chain.

ℹ️ Any unprivileged local task can issue the requeue-PI futex operations — the bug needs no special device, capability, or unprivileged user namespace, and it is not architecture-specific. There is therefore no configuration knob that closes it short of the kernel patch (see Mitigation). Only the kernel backport flips a verdict here.

Vulnerable commit range

The reachable lifetime is therefore v2.6.39 (2011) through v7.0; ≥ 7.1 carries the fix. The flaw is in generic locking code, so every CPU architecture is affected — there is no architecture exemption.

Patch status

The deciding fact per row is whether the kernel carries the 3bfdc63936dd backport. Because the bug dates to v2.6.39, every kernel below is inside the affected window — there are no “predates the bug” rows here — and the trigger needs no privilege or special configuration, so the kernel version is the whole story: a row is :x: until its kernel ships the fix.

The first group tracks the upstream kernel itself; the rest are a focused set of general-purpose and container-host distributions. Current kernel is the latest version observed in the row’s user-facing channel; First fixed is the first release or build carrying the fix, and Fixed since the date it first held (both stay — while a row is vulnerable).

Linux kernel

The fix reached Linus as v7.1 and the stable maintainers backported it across every maintained line. 7.0.y took the backport in 7.0.4, well before that line reached end of life at 7.0.14. The pre-6.1 longterm lines (5.15.y, 5.10.y) received the backport on 2026-07-24.

When verifying a tree directly, the fixed function is remove_waiter() in kernel/locking/rtmutex.c; the fix replaces the use of current / current->pi_lock with the waiter’s own waiter->task.

Debian

Debian’s linux is affected in every suite (the bug predates all of them); the security tracker’s CVE-2026-43499 record drove these assessments. bullseye (LTS) resolved last: the default src:linux carries the fix as of the 2026-08-04 upload (5.10.262-1, DLA-4717-1), built on the upstream 5.10.262 tarball — past the upstream fix (5.10.261, 2026-07-24) — landing before bullseye LTS ends 2026-08-31. The opt-in linux-6.1 package — the bookworm 6.1 kernel rebuilt for bullseye, shipped via bullseye-security — resolved earlier, at 6.1.176-1~deb11u1 (DLA-4671-1, 2026-07-04).

Proxmox VE

Proxmox ships its own Ubuntu-derived kernels (proxmox-kernel-*), so Debian’s fix status does not carry over — and as a common VM/container host, the container-escape vector makes it worth tracking. Each PVE release’s default kernel series (pinned by proxmox-default-kernel) and its opt-in series get their own rows above; the current defaults are the 7.0 series on PVE 9 and 6.8 on PVE 8. A live series can gain the fix two ways: by rebasing onto its Ubuntu base once Canonical fixes it — PVE 8’s default 6.8 got the fix that way, rebasing onto noble’s 6.8.0-136.136 (USN-8488-1) in 6.8.12-39-pve, with no GhostLock-specific changelog entry — or as Proxmox’s own cherry-pick, as with the 6.17 fix, three patches taken from linux-6.18.y on 2026-07-09. Note that Ubuntu maintaining a series matters more than kernel.org: 6.8.y has long been EOL upstream, yet noble’s 6.8 keeps receiving fixes.

An opt-in series is Proxmox’s preview of a likely next default, aimed at setups that need newer hardware support; an old series is one the release has moved past — a superseded default like PVE 9’s 6.17, or an opt-in overtaken by a newer one. Proxmox discontinues updates for superseded series once a short transition tail ends (the 6.17 cherry-pick above landed inside that tail), and every superseded PVE kernel series is EOL both on kernel.org and in Ubuntu, so past the tail a fix could only ever arrive as a Proxmox cherry-pick that will not come.

The 6.14 and 6.11 series have no rows: their updates had already ended before this tracker existed, without the fix. The 6.14 series — PVE 9’s original default, superseded by 6.17 on 2025-11-11, and its PVE 8 opt-in rebuild, whose Ubuntu 6.14 HWE source has also left support — last built 6.14.11-9 / 6.14.11-9~bpo12+1 on 2026-05-15; PVE 8’s 6.11 opt-in, overtaken by 6.14, last built 6.11.11-2 on 2025-03-16. With PVE 8 itself reaching end of life in August 2026, no fix source remains for any of them: a host still booted into a 6.14 or 6.11 kernel stays vulnerable, and the exit is rebooting into the release’s current default kernel — PVE 9’s 7.0 series or PVE 8’s 6.8 (6.8.12-39-pve or later), both fixed.

Rocky Linux / RHEL family

RHEL-family kernels carry security backports without moving their upstream base version, so the version string alone cannot confirm a fix — the signal is an erratum. The table rows track the standard kernel; the niche real-time kernel-rt variant is covered only here. RHEL is upstream of the rebuilds, and the fix flowed RHEL → AlmaLinux → Rocky:

• Standard kernel, EL10 / EL9 — Red Hat shipped RHSA-2026:38492 (RHEL 10.2, kernel 6.12.0-211.33.1.el10_2) and RHSA-2026:38491 (RHEL 9, kernel 5.14.0-687.25.1.el9_8) on 2026-07-13; AlmaLinux rebuilt both as ALSA-2026:38492 / ALSA-2026:38491, and Rocky shipped the matching RLSAs in the table above.
• Standard kernel, EL8 — Red Hat shipped RHSA-2026:39083 (kernel 4.18.0-553.143.1.el8_10); AlmaLinux rebuilt it as ALSA-2026:39083. Rocky 8 skipped that NVR — rather than publishing a standalone rebuild of 553.143.1, it shipped the cumulative 4.18.0-553.144.1.el8_10 as RLSA-2026:39179.
• kernel-rt, EL9 GA — still vulnerable — Red Hat shipped RHSA-2026:39983 (kernel-rt 5.14.0-284.181.1.rt14.466.el9_2) for the RHEL 9.2 E4S path only; there is no advisory for the GA stream and no RLSA rebuild in Rocky’s NFV repo, and Red Hat’s kernel-rt package state remains Affected for RHEL 9 GA.
• kernel-rt, EL8 — Red Hat shipped RHSA-2026:39082 (kernel-rt 4.18.0-553.143.1.rt7.484.el8_10) on 2026-07-14; Rocky 8’s RT repo carries the cumulative 4.18.0-553.144.1.rt7.485.el8_10, which supersedes the RHEL fixed NVR.

The standard kernel is thus fixed for RHEL 10, RHEL 9, Oracle Linux, CloudLinux OS, and Rocky 8; the EL9 GA kernel-rt stream is the one still waiting.

Amazon Linux

Each AL2023 kernel stream is its own row above; status is verified from the repodata updateinfo.xml (the per-CVE ALAS pages are JS-rendered and don’t fetch headlessly). The default row is the plain kernel package (a 6.1-series stream); the 6.12 and 6.18 opt-in rows are the kernel6.12 and kernel6.18 packages.

AL2 (amzn2) is not tracked here: it reached end of support on 2026-06-30 — before this tracker existed — with no ALAS ever issued for this CVE, and AWS no longer provides security updates or bug fixes for AL2 core packages. All three of its kernel streams (4.14, plus 5.10 / 5.15 via amazon-linux-extras) are in-window and permanently vulnerable, and no fix is expected. The exit is migrating to AL2023 (or another patched distribution).

Detection

GhostLock is architecture-independent and needs no special configuration, so the only question is whether the running kernel is inside the affected window and missing the fix. Compare the running kernel against the Patch status table above — the Linux kernel rows for the upstream point releases, and your distribution’s row:

uname -r

Any mainline kernel ≥ 7.1, or one at or above its branch’s first-fixed release (7.0.4 / 6.18.27 / 6.12.86 / 6.6.140 / 6.1.175 / 5.15.212 / 5.10.261), carries the fix; anything else in the 2.6.39–7.0 window without a distro backport is vulnerable. On RHEL-family and Amazon kernels the base version does not map to an upstream point release — rely on the distribution’s advisory state (see the rows above) rather than the number alone.

Public PoC

The upstream PoC is in NebuSec/CyberMeowfia (under IonStack/CVE-2026-43499); it constructs the three-futex requeue-PI deadlock and triggers the buggy remove_waiter() rollback from an unprivileged process. Do not run it on a system you are not authorised to test.

Mitigation

There is no effective mitigation short of installing a patched kernel. The trigger is ordinary futex(2) requeue-PI (FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, FUTEX_CMP_REQUEUE_PI), available to every process; it cannot be disabled, and the bug needs neither elevated privilege nor unprivileged user namespaces — so namespace-hardening knobs such as kernel.unprivileged_userns_clone=0 do not block it.

Install a kernel that carries the 3bfdc63936dd backport: mainline ≥ 7.1, or 7.0.4, 6.18.27, 6.12.86, 6.6.140, 6.1.175, 5.15.212, 5.10.261.

Until you can reboot into a fixed kernel, the only risk reduction on multi-tenant and container hosts is ordinary defence-in-depth that does not touch the hole itself — limit untrusted local logins and untrusted container workloads until the host kernel is patched.

Risk notes

• Unprivileged local users: on an unpatched in-window kernel, any local user can escalate to root — shared multi-user hosts, CI runners, and login servers are directly in scope.
• Container escape: the bug is reachable from inside an unprivileged container, so a hostile or compromised container can break out to the host. Multi-tenant container platforms are the headline risk.
• Architecture-independent: rtmutex and futex requeue-PI are generic kernel code — there is no “this architecture is safe” caveat.
• No mitigation short of patching: unlike bugs gated by a device node or a namespace toggle, there is no knob to turn; only the kernel backport removes the hole.
• Long exposure window: the flaw dates to v2.6.39 (2011), so essentially every unpatched production kernel is affected. The fix is in mainline 7.1 and backported to 7.0.4, 6.18.27, 6.12.86, 6.6.140, 6.1.175, 5.15.212, and 5.10.261 — check your distribution row.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the advisory, repository index, or git reference that established each fact — so any row can be audited or reproduced. Most readers never need it.

References