CVE-2026-43499

What it actually does

This is a local Linux kernel use-after-free vulnerability in the real-time mutex priority-inheritance code path. During proxy-lock rollback triggered through futex requeue operations, the kernel's remove_waiter() logic used the current task instead of the waiter task being removed. That can leave stale priority-inheritance state, perform queue manipulation without the correct task lock, and leave a dangling pi_blocked_on pointer. A local authenticated attacker able to exercise futex priority-inheritance behavior may be able to corrupt kernel memory, causing denial of service or potentially achieving kernel-level privilege escalation.

Why it matters to the business

Successful exploitation can let a user or compromised low-privilege process gain full control of an affected Linux system, tamper with data, disable security tooling, or crash production workloads. Because the flaw is in the Linux kernel, exposure may exist across servers, containers, appliances, and embedded systems that use affected downstream kernels. Although this issue is not currently listed in CISA KEV and public exploit maturity is reported as none, the presence of named threat actor interest increases the need to prioritize patch validation on multi-user systems, internet-facing Linux infrastructure, shared hosting, CI/CD runners, and container hosts.

How an attack unfolds

An attacker first obtains the ability to run local code as an unprivileged user or through a compromised application account. They then execute code that repeatedly exercises futex priority-inheritance and requeue behavior, specifically paths involving futex_requeue(), rt_mutex_start_proxy_lock(), and rollback from proxy locking. The vulnerable kernel may remove the wrong task from the real-time mutex wait queue and leave stale priority-inheritance state behind. By shaping timing, task scheduling, and heap reuse, the attacker attempts to turn the dangling pointer into controlled kernel memory corruption. The most likely immediate result is a kernel crash, but reliable exploitation could allow arbitrary kernel read/write primitives and privilege escalation to root. Threat reporting names GhostLock in connection with this CVE, so defenders should treat suspicious local futex-heavy activity and unexplained kernel crashes on unpatched systems as potentially relevant.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the upstream fix changing remove_waiter() to operate on waiter::task instead of current in the rtmutex code. No exact fixed package versions were provided in the input, so rely on vendor advisories for Red Hat, Ubuntu, Debian, SUSE, Oracle, Amazon Linux, Android, appliance vendors, and any custom kernel maintainers. Reboot into the patched kernel after installation; merely installing the package is insufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, isolating multi-tenant systems, hardening container hosts, disabling or constraining untrusted CI runners, and using mandatory access controls such as SELinux/AppArmor. These mitigations reduce exploitation opportunities but do not remove the vulnerable kernel code path.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, is patched. Use uname -a or /proc/version to identify the active kernel and compare it against the vendor advisory that includes the rtmutex remove_waiter() fix. On source-based or custom kernels, verify that kernel/locking/rtmutex.c contains the corrected logic using waiter::task in remove_waiter() and related priority-inheritance operations. After patching, reboot and confirm the host is running the updated kernel. Validate fleet exposure by inventorying Linux kernel versions across servers, container hosts, virtual machines, appliances, and golden images. For high-risk systems, review recent kernel crash logs before and after patching for rtmutex, futex, priority-inheritance, KASAN, general protection fault, or use-after-free traces.

Typical attack path

1. Gain local code execution on an affected Linux system through a shell, compromised service account, container escape prerequisite, CI job, or malicious local user session.
2. Run a crafted program that creates multiple threads or processes using priority-inheritance futexes and futex requeue operations.
3. Trigger the rt_mutex_start_proxy_lock() rollback path where remove_waiter() acts on the wrong task context.
4. Induce stale pi_blocked_on state or unsafe wait-queue manipulation to create a use-after-free condition in kernel memory.
5. Attempt to reuse the freed kernel object through controlled allocations and scheduling races.
6. Escalate privileges to root or kernel context, or crash the kernel if exploitation is unreliable.
7. Use elevated privileges to persist, disable defenses, access sensitive data, or move laterally.

How to detect it

Look for evidence of prior local exploitation rather than only vulnerability presence. Relevant sources include kernel logs from journald and syslog, dmesg output, persistent kernel crash logs, kdump/vmcore data, EDR process telemetry, auditd exec events, sudo/authentication logs, file integrity monitoring, and container/CI execution logs. Search for kernel oops or panic traces mentioning rtmutex, futex, priority inheritance, remove_waiter(), rt_mutex_start_proxy_lock(), futex_requeue(), pi_blocked_on, use-after-free, KASAN, general protection fault, or BUG messages. Also investigate suspicious locally executed binaries, especially short-lived multithreaded programs launched from world-writable directories such as /tmp, /var/tmp, /dev/shm, user home directories, or CI workspaces shortly before a kernel crash or privilege change. Post-exploitation indicators may include unexpected root-owned files, new setuid binaries, modified SSH authorized_keys, disabled security services, kernel module loading, or audit log gaps. There are no reliable network-only indicators because exploitation is local.

• remove_waiter
• rt_mutex_start_proxy_lock
• futex_requeue
• rt_mutex_adjust_prio_chain
• pi_blocked_on
• rtmutex
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG at kernel/locking/rtmutex.c
• kernel/locking/rtmutex.c
• Unable to handle kernel paging request
• BUG: unable to handle page fault
• Oops:
• Kernel panic - not syncing
• /tmp/
• /var/tmp/
• /dev/shm/

What your security team should do

• Prioritize patching shared Linux systems, container hosts, virtualization hosts, CI/CD runners, developer jump boxes, and any servers where untrusted or semi-trusted users can execute code.
• Reboot systems after kernel updates and verify the running kernel version matches the patched vendor release.
• Search endpoint, syslog, journald, and crash dump telemetry for recent kernel oops, panic, KASAN, rtmutex, futex, or use-after-free messages.
• Treat unexplained local privilege escalation, root shell creation, kernel crashes, or security control tampering on unpatched systems as high-priority investigation leads.
• Add temporary monitoring for unusual execution of locally compiled binaries from /tmp, /var/tmp, /dev/shm, home directories, and CI workspaces on vulnerable hosts.
• Limit local interactive access and untrusted workload execution until patching is complete.
• For containerized environments, remember that the host kernel is the security boundary; patch container hosts even if container images appear up to date.
• Track vendor advisories for exact fixed kernel package versions because downstream distributions may backport the fix without changing to a visibly new upstream kernel version.
• If GhostLock activity is relevant to the organization’s threat model, correlate this vulnerability with other local privilege-escalation attempts, post-compromise tooling, and persistence artifacts on Linux hosts.