CVE intelligence

CVE-2026-43499

Vulnerability intelligence

Published May 21, 2026Sources checked Oct 27, 2026

7.8HIGHCVSS out of 10

What this means

Review the available evidence

CVE-2026-43499 and is rated High severity with a CVSS score of 7.8. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

What to do next

Remediation and response

Ubuntu Security Notices guidance

Vendor revision: Sep 22, 2026

Vendor remediation details

This update corrects flaws in the following subsystems: - x86 architecture; - InfiniBand drivers; - Network drivers; - NVME drivers; - Ext4 file system; - SMB network file system; - IPv4 networking; - Network traffic control; - TCP network protocol; - Locking primitives; - IPv6 networking; - Multipath TCP; - Netfilter; - Open vSwitch; - SCTP protocol; - SMC sockets; (CVE-2026-31414, CVE-2026-31448, CVE-2026-31705, CVE-2026-43198, CVE-2026-43378, CVE-2026-43499, CVE-2026-46266, CVE-2026-46331, CVE-2026-52924, CVE-2026-52989, CVE-2026-53086, CVE-2026-53176, CVE-2026-53212, CVE-2026-53215, CVE-2026-53224, CVE-2026-53225, CVE-2026-53228, CVE-2026-53246, CVE-2026-53359, CVE-2026-64531)

Ubuntu Security Notices guidance

Vendor revision: Sep 18, 2026

Vendor remediation details

This update corrects flaws in the following subsystems: - x86 architecture; - Cryptographic API; - InfiniBand drivers; - Media drivers; - NVIDIA Tegra memory controller driver; - Network drivers; - NVME drivers; - File systems infrastructure; - Ext4 file system; - OCFS2 file system; - IPv4 networking; - Network traffic control; - TCP network protocol; - Locking primitives; - B.A.T.M.A.N.

Ubuntu Security Notices guidance

Vendor revision: Sep 2, 2026

Vendor remediation details

CISA KEVNot listedBased on the latest collected catalog

EPSS0.9%Estimated 30-day exploitation probability

Ransomware useNot markedCISA KEV ransomware field

Threat actors0Source-linked actor relationships

Overview

What is CVE-2026-43499?

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 ]

Source: NVD