CVE-2026-43499

rtmutex: Use waiter::task instead of current in remove_waiter()

No known exploitation. EPSS puts it in the 18th percentile. A vendor fix is available.

CVSS 3.17.8High EPSS percentile18th0.3% chance in 30 days CISA KEVNot listedNo confirmed exploitation
No public exploit known FixVendor fixNo build named by the sources

Published 2026-05-21Updated 2026-09-08Sources: CVE.org, NVD

NVD CVE.org

What to do

The vendor has published a fix. Version details are below where the sources state them.

Steps

Written by AI from the record

Check your Linux kernel version (e.g., run uname -r).
Compare it against the fixed kernel versions listed below and confirm whether your version includes the fix.
Update your Linux kernel to include the fix (choose the matching line from the list of fixed versions for your distribution’s kernel branch).
Reboot after applying the kernel update so the new kernel is actually running.
If you cannot patch immediately, reduce local access to the affected machines (tighten who can log in) until the kernel is upgraded.

Vendor advisory Usually a quick update

Check it yourselfA free OpenVAS check exists for this CVE. Run it against your hosts.Is your organisation exposed?Request an assessment to establish which checks fit your systems.

What it is

From the CVE record

In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ]

In plain language

Written by AI from the record

This Linux kernel bug can let a local attacker crash the system (and possibly gain higher privileges) by triggering a mistake in real-time mutex cleanup; small businesses should patch because it’s a high-impact local issue, but there’s no clear evidence of real-world attacks.

CVE-2026-43499 is a Linux kernel real-time mutex (rtmutex) flaw where remove_waiter() uses the wrong task context (“current” instead of the waiter task), which can cause use-after-free conditions and incorrect priority/PI state handling; it requires low-effort local access.

If you're affected

System crash (denial of service)
Possible privilege escalation
Service outage during exploitation
Compromise of worker processes

What is it

Think of the kernel as the “traffic controller” that coordinates shared resources between processes. This bug happens during cleanup of a real-time mutex (a lock used for timing-critical work). Under the right local conditions, the kernel can end up referencing the wrong task details, which can make the system unstable (crash) and may even let an attacker take more control than they should.

Who is affected

This matters if you run a Linux machine whose kernel is vulnerable (the affected product is the Linux kernel). Because the issue needs local access, it’s mainly a concern for systems where an attacker already has some ability to run code or log in. It’s only a meaningful risk if someone can gain local access (the findings do not specify a guaranteed default exposure path).

How urgent is it

This is an AMBER issue: it can lead to denial of service and potentially privilege escalation, but there’s no clear evidence of exploitation in the wild and no public exploit code reported. Because it’s local and requires attacker access, the immediate “worm-like” risk is lower—still, you should patch to remove the opportunity for local escalation or crashes.

What to do — in detail

Confirm exposure
- On each affected Linux host, check the running kernel version: uname -r.
- Determine whether your distribution’s kernel package already includes the fix corresponding to one of the fixed versions below.
Identify the correct fixed kernel for your branch
- Fixed in commit: d8cce4773c2b23d819baf5abedc62f7b430e8745
- Fixed in commit: 8a1fc8d698ac5e5916e3082a0f74450d71f9611f
- Fixed in commit: 6d52dfcb2a5db86e346cf51f8fcf2071b8085166
- Fixed in commit: 3fb7394a837740770f0d6b4b30567e60786a63f2
- Fixed in commit: 88614876370aac8ad1050ad785a4c095ba17ac11
- Fixed in commit: 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349
- Fixed in release: Linux 6.1.175
Upgrade / patch
- Upgrade to a kernel build that includes the fix (use your vendor/distribution’s recommended kernel update for your kernel branch that maps to one of the fixed versions above).
- After updating, reboot immediately to ensure the patched kernel is the one currently running.
If patching is delayed (temporary containment)
- Reduce the chance of an attacker getting “local access”: restrict who can log in, limit shell access, harden remote access paths, and review any services that allow users to run code on the host.
What to monitor
- Look for unusual crashes or kernel warnings around real-time mutex usage patterns on systems where local access attempts may be occurring.
- Re-check after patching that the host is actually running the updated kernel (not just that the package was downloaded).

Technical context

Severity is HIGH (CVSS 7.8) with local attack conditions and no user interaction required per the findings. The weakness maps to CWE-416 (use-after-free). Mechanism: in Linux rtmutex, remove_waiter() operates on “current” even when it should operate on the waiter task; this mis-handles pi_lock ownership and leaves waiter task PI state uncleared, creating a dangling pointer and potential use-after-free, plus incorrect priority adjustment behavior. Exploitation status: no KEV listing and no clear dated news reporting; incidents in the wild are not reported, and no public exploit code is on record. Fix availability: multiple fixed commits are listed, and Linux 6.1.175 is a fixed release. EPSS is a low predicted value and flat trend, but it is not driving urgency here because the guidance is based primarily on the confirmed-fix and impact; KEV is not present.

This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS18th

CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.3% chance of exploitation activity in the next 30 days, which ranks it in the 18th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

18 events over 110 days, from the signal feeds we watch.

2026-09-08Patch availablerecord updated
2026-08-26Patch availablerecord updated
2026-08-22Patch availablerecord updated
2026-07-24Patch availablerecord updated
2026-07-23Patch availablerecord updated
2026-07-08Patch availablerecord updated

Affected products

Linuxoss-projectaka the linux kernel
- LinuxOSOn-premOperating Systems / linux-distro

And 1 more affected product. See all after sign-in

Technical detail

CVSS 3.1 vector

Open in the CVSS calculator

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Scored 7.8 by NVD.

How it is reached

Attack Vector LocalRequires local access to the vulnerable system (e.g. local login, malicious file)
Attack Complexity LowNo special conditions — the attack can be reliably reproduced
Privileges Required LowRequires basic user-level privileges
User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

Confidentiality HighTotal information disclosure — all data in the component is compromised
Integrity HighTotal loss of integrity — attacker can modify any data in the component
Availability HighTotal denial of service — the component is completely unavailable