Am I vulnerable?
CVE-2026-43499 is a local privilege-escalation flaw in the Linux kernel's rtmutex (real-time mutex) code, reachable from userspace through the futex syscall. A logic error in the priority-inheritance lock rollback path lets a local, low-privileged process corrupt kernel locking state, which is the kind of primitive that reliably escalates to root. NVD scores it CVSS 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). The bug was introduced in 2.6.39 (2011), so effectively every modern kernel before the fix is affected.
Affected and fixed versions
Fixed upstream in the following stable releases (and mainline 7.1). Anything on a supported branch below its fix, or on an end-of-life branch back to 2.6.39, is vulnerable.
| Branch |
Fixed in |
| 6.1 LTS |
6.1.175 |
| 6.6 LTS |
6.6.140 |
| 6.12 LTS |
6.12.86 |
| 6.18 |
6.18.27 |
| 7.0 |
7.0.4 |
| mainline |
7.1 |
Diagnostic checks (read-only)
- Vanilla or stable kernels:
uname -r and compare against the fix for your branch above.
- Distribution kernels (important caveat): RHEL, Ubuntu, Debian, SUSE, and Amazon Linux backport fixes without changing the upstream-looking version, so the numbers above do NOT map to a distro
uname -r. Check your distribution's security advisory or errata for CVE-2026-43499 and match against its package version (for example rpm -q kernel, dpkg -l 'linux-image*').
- Fleet: pull kernel package versions from your configuration-management or vulnerability scanner and match them against each distribution's fixed build for this CVE.
- Exposure weighting: hosts that run untrusted local code (multi-tenant servers, CI runners, container hosts, shared shells) are the ones where a local-only bug matters most.
Vulnerability
The kernel's remove_waiter() helper dequeues a waiter using current, the task that is running. That assumption holds on the normal slow-lock paths, but not for one case: proxy-lock rollback in rt_mutex_start_proxy_lock() when it is invoked from futex_requeue(). There, the waiter being removed belongs to a different task, so remove_waiter() operates on the wrong task's rtmutex bookkeeping. The fix (commit title "rtmutex: Use waiter::task instead of current in remove_waiter()") makes the dequeue act on waiter::task instead of current.
Operating on the wrong task corrupts kernel locking structures, and because the trigger is reachable from userspace through the futex syscall with only local, low privileges, it is a strong privilege-escalation candidate. The PI-futex and requeue machinery has a long history as the most productive local-privesc surface in the Linux kernel (the 2014 futex requeue bug behind Towelroot is the canonical example), and exploit developers know this code well. We are not aware of a public exploit for this specific CVE in our index, but the class is one that gets weaponized, so patch on the assumption that a reliable exploit is achievable.
Threat model
Who would exploit this: any actor who already has the ability to run unprivileged code on the host and wants root. That includes a local user on a shared system, a compromised service account after an initial web or app exploit, a process inside a container aiming to escape to the host, and malware doing post-exploitation escalation. This is not remotely exploitable on its own, so it is a second-stage tool, but on Linux that stage is nearly always present in a real intrusion.
What they gain: full root on the host. From an unprivileged foothold the attacker reaches kernel-level control, which means disabling security controls, reading any file and secret, installing persistence, and tampering with logs and monitoring.
Attack chain: obtain local unprivileged execution (a login, a container workload, or code execution from another bug), craft a futex requeue scenario that drives the proxy-lock rollback with a mismatched waiter, corrupt kernel state, and escalate to root.
Blast radius: the entire host. On container hosts the concern is sharper: all containers share the host kernel, and the futex syscall is permitted by the default seccomp profile, so a container breakout to host root is realistic wherever containers run untrusted or semi-trusted workloads. On multi-tenant and CI systems, any tenant or job becomes a path to full-node compromise.
Mitigation
Patch
Update the kernel to the fixed release for your branch (table above), or to your distribution's patched build for CVE-2026-43499, and reboot. Kernel privilege-escalation fixes require a reboot (or live-patching where supported) to take effect.
Compensating controls
Kernel LPE bugs have few good mitigations short of patching, but you can reduce exposure:
- Prioritize multi-tenant and container hosts. These are where a local-only bug becomes a breakout. Patch them first.
- Reduce untrusted local code. Limit who can run code on sensitive hosts, and separate untrusted workloads onto dedicated, closely-monitored nodes.
- Live-patch where available. If you use kernel live-patching (kpatch, Ksplice, kernelcare), check whether a live patch for this CVE is offered to close the window without a reboot.
- Do not rely on blocking futex. The futex syscall is fundamental to glibc locking and cannot be seccomp-blocked without breaking normal programs, so it is not a viable mitigation.
Detection
Be honest about scope: this is an on-host kernel bug with no network component and no file artifact on your infrastructure, so web Sigma rules and file YARA signatures do not apply. Detection is version compliance plus host behavioral monitoring.
- Kernel version compliance (primary). Inventory kernel versions across the fleet and flag any host that is not on its distribution's fixed build for CVE-2026-43499. That list is your exposure.
- Host behavioral monitoring. An EDR or auditd can surface the aftermath rather than the trigger: an unexpected transition of a process to UID 0, a normally-unprivileged service spawning a root shell, or new kernel modules and persistence. Alert on unprivileged-to-root transitions outside known setuid paths.
- Kernel logs. An unreliable exploit attempt may leave
WARNING, BUG, or rtmutex-related oops entries in dmesg/journald before it succeeds. Collect kernel logs centrally and alert on lock-subsystem warnings.
References