Mitigating GhostLock (CVE-2026-43499, CVE-2026-53163) on Rocky Linux 8, 9, 10, and LTS Variants

cve security kernel rocky linux lts mitigation troubleshooting

Arsalan Zaidi
Customer Support Engineer

Jul 08, 2026

Introduction

GhostLock is a pair of related vulnerabilities in the Linux kernel real-time mutex (rtmutex) subsystem:

CVE-2026-43499 is a use-after-free in the remove_waiter() function in kernel/locking/rtmutex.c. When a FUTEX_CMP_REQUEUE_PI operation returns -EDEADLK, the rollback path clears pi_blocked_on on the wrong task (the current thread instead of the actual waiter), leaving the waiter with a dangling pointer to a freed stack frame.
CVE-2026-53163 is a bug introduced by the fix for CVE-2026-43499 in the same remove_waiter() function. The two fixes must be applied together.

An unprivileged local user can trigger the CVE-2026-43499 race to crash the kernel (denial of service) or, with a more sophisticated exploit chain, achieve local privilege escalation. Public exploit code is available, including a denial-of-service proof-of-concept and a full privilege escalation chain targeting mobile platforms.

CVE-2026-43499 was introduced in Linux 2.6.39 (commit 8161239a8bcc) and fixed upstream in v7.1-rc1 (commit 3bfdc63936dd). CVE-2026-53163 is fixed by commit 40a25d59e85b. Both fixes must land together. No special privileges or kernel configuration beyond the default CONFIG_FUTEX_PI=y are required to trigger the bug.

Problem

GhostLock affects any Linux system running a kernel between versions 2.6.39 and 7.1-rc1 with futex PI support enabled (the default configuration). Exploitation requires only local code execution.

Treat the following systems as affected unless they are running a patched kernel listed in the Patched Kernels section:

Rocky Linux 8, 9, and 10 community releases
Rocky Linux 8 and 9 LTS variants
RLC Pro FIPS variants
RLC Pro variants based on Rocky Linux 8, 9, or 10, including RLC Pro Hardened

Any system with local shell users, shared application accounts, CI runners, or workloads capable of running untrusted code should be treated as exposed until patched. The vulnerability cannot be exploited remotely on its own, but remote code execution on the system would enable the local exploit.

Status

Patched kernels are not yet available. CIQ Engineering is actively building patched kernels for all supported variants. This article will be updated as builds become available.
No effective runtime mitigation exists. See the Mitigation section for partial hardening measures.
CIQ Bridge and CentOS 7.9 systems are also affected.
Open a support case if you need help assessing exposure or tracking patched kernel availability for a specific CIQ variant.

Patched Kernels

No patched kernels are available yet. This table will be updated as CIQ Engineering releases fixes for each variant.

Variant	Patched Kernel Version	Released
RLC Pro LTS 8.6	pending
RLC Pro LTS 8.10	pending
RLC Pro LTS 9.2	pending
RLC Pro LTS 9.4	pending
RLC Pro LTS 9.6	pending
RLC Pro FIPS 8.6	pending
RLC Pro FIPS 8.10	pending
RLC Pro 8	pending
RLC Pro 9	pending
CIQ SIG/Cloud Next 8	pending
CIQ SIG/Cloud Next 9	pending
CIQ SIG/Cloud Next 10	pending
CIQ Linux Kernel LT 6.12	pending
Rocky Linux 8.10 (Community)	pending
Rocky Linux 9.x (Community)	pending
Rocky Linux 10.x (Community)	pending

Confirm what is running on a given system with:

uname -r

Installing the Update

Once patched kernels are released, install them with:

RLC Pro LTS and FIPS Variants

sudo dnf update kernel*

Reboot into the new kernel after the update completes. No additional repository configuration is needed; the update is available from the LTS or FIPS repository.

RLC Pro and CIQ SIG/Cloud Next Variants

sudo dnf update kernel*

Reboot into the new kernel. If the update does not appear, run sudo dnf clean all && sudo dnf makecache to refresh repository metadata.

Community Edition (RESF)

sudo dnf update kernel*

Reboot into the new kernel. The fix will be available from the standard BaseOS repository once the upstream patch is integrated.

Mitigation

There is no runtime mitigation that fully prevents the GhostLock vulnerability. The affected code path (FUTEX_CMP_REQUEUE_PI) is part of the POSIX futex subsystem and cannot be disabled through sysctl, module blocking, or namespace restrictions without breaking standard threading primitives used by glibc and most multithreaded applications.

The following kernel hardening options reduce the exploitability of the underlying use-after-free, but do not prevent the denial-of-service crash:

Partial hardening: randomize_kstack_offset

Rocky Linux 9 kernels ship with CONFIG_RANDOMIZE_KSTACK_OFFSET=y compiled in, but the feature is disabled by default. Enabling it at boot adds approximately 5 bits of randomization to kernel stack frame placement, which breaks the stack-reclaim technique needed for the privilege escalation chain. It does not prevent the DoS PoC from crashing the kernel.

To enable on the next boot, add the kernel parameter:

sudo grubby --update-kernel=ALL --args="randomize_kstack_offset=on"

Reboot for the change to take effect. Verify with:

cat /proc/cmdline | grep randomize_kstack_offset

Rocky Linux 8 kernels (4.18.x) do not include this feature.

Verification

To verify whether a system is running a patched kernel once one is available:

uname -r

Compare the output against the Patched Kernels table above. If the running kernel version matches or is newer than the patched version listed for your variant, the fix is in place.

To check whether randomize_kstack_offset is enabled (partial hardening only):

cat /proc/cmdline | grep -o "randomize_kstack_offset=[a-z]*"

If the output reads randomize_kstack_offset=on, the hardening is active.

Resolution

Once patched kernels are available:

Update the kernel: sudo dnf update kernel*
Reboot into the new kernel
Verify the running kernel with uname -r
If randomize_kstack_offset=on was added as a temporary hardening measure, it can be left in place (no negative impact) or removed with sudo grubby --update-kernel=ALL --remove-args="randomize_kstack_offset=on"

Notes

The GhostLock DoS proof-of-concept requires no privileges and no special kernel modules. It uses only standard futex system calls available to any unprivileged user. Blocking the exploit through seccomp or AppArmor would require filtering SYS_futex with FUTEX_CMP_REQUEUE_PI, which would break most threaded applications.
The full privilege escalation exploit published by the researchers targets Android (aarch64) and relies on platform-specific techniques (PR_SET_MM_MAP, inet6_protos overwrite, CPU Entry Area gadgets). The researchers note that adaptation to x86_64 Linux is feasible but requires different targets and offsets.
Systems running CONFIG_STATIC_USERMODE_HELPER=y are partially protected against the specific "DirtyMode" escalation path that rewrites /proc/sys/kernel/core_pattern, but not against the underlying UAF or alternative escalation techniques.
The fixes for CVE-2026-43499 and CVE-2026-53163 must be applied together. Do not ship commit 74e144274af3 without the revert 39def6d250d3. That commit is a bad second fix for a case that CVE-2026-53163's fix already covers. Branches carrying it (such as ciq-6.18.y / CLK-6.18) need the revert backported.