CVE-2026-43499 is a use-after-free in the Linux kernel's rtmutex implementation, and the root cause is more subtle than a typical missing null check. The remove_waiter() function was written with an undocumented assumption: the task whose waiter is being removed is always 'current'. It uses the global 'current' for pi_lock operations, dequeue logic, and clearing pi_blocked_on — never receiving the target task as an explicit parameter. That assumption held until futex_requeue() introduced a proxy-lock rollback path that calls remove_waiter() on a task other than the current one.
The UAF manifests as a dangling pi_blocked_on pointer. When remove_waiter() operates on the wrong task without holding its pi_lock, the rbtree state and the task's blocking state can diverge. The pi_blocked_on pointer then becomes a stale handle pointing into freed or repurposed memory, and anything that traverses the priority inheritance chain can touch it.
The fix replaces 'current' with 'waiter::task' throughout remove_waiter(), making the function operate on the correct task regardless of caller context. This is a one-line semantic change that resolves the UAF but does not refactor the function's contract — remove_waiter() now effectively operates in two different modes depending on whether the caller is a slowlock path (where waiter::task equals current by coincidence) or the futex rollback path (where it does not).
What you should check: whether your kernels have the futex_requeue proxy-lock code path enabled (CONFIG_FUTEX=y, and the specific requeue implementation varies by version), whether any real-time or userspace workloads use futex requeue operations that could trigger rollback, and whether tasks using PI-futexes can reach the problematic code under contention. The entry point to this code is user-accessible — futex_requeue() is a syscall — but the rollback conditions that make the UAF reachable are narrow. Monitor for crashes in the PI chain traversal code, particularly in paths involving rt_mutex_proxy_unlock() or related finishers.
The broader concern: other rtmutex internal functions likely carry the same implicit 'current' assumption. The subsystem has historically added callers without auditing invariants. Treat this as a pattern bug — even after patching, audit new code that calls into rtmutex internals from non-current contexts.