Live › vulnerability › CVE-2026-99169
Go to dashboardA shared futex can be requeued onto a memory map that has been freed, so waiters on a freed mm consume wakeups meant for a newly allocated mm at the same address. The fix keys shared futexes by a unique 64-bit per-mm ID instead of the address.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 11:32 UTC. All times on this page are UTC.
Systems running a Linux kernel that includes the futex mm-reuse change; the sources do not list affected kernel versions. Multi-threaded processes that set clear_child_tid into anonymous memory use this path implicitly. Private futexes are not changed by the fix.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
futex: Fix mm reuse handling for FUT_OFF_MMSHARED
A FUT_OFF_MMSHARED futex is a shared futex that refers to an MM. It is possible for a process to wait on a shared futex with a different MM because a FUT_OFF_INODE waiter can be requeued onto a FUT_OFF_MMSHARED futex by another process. This can cause FUT_OFF_MMSHARED waiters on a freed MM to consume wakeups intended for a newly allocated MM at the same address.
Fix it by keying FUT_OFF_MMSHARED using a unique 64-bit per-MM ID. Leave private futexes as before to avoid influencing the performance of the hotpath.
(Multi-threaded processes typically implicitly use FUT_OFF_MMSHARED by setting clear_child_tid such that it points into anonymous memory, which causes mm_release() in a multi-threaded mm to perform FUTEX_WAKE.)
This page as .md · .json · in your agent: get_signal("CVE-2026-99169")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.