UBUNTU-CVE-2026-99169: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: futex: Fix mm reuse handling for FUTOFFMMSHARED A FUTOFFMMSHARED 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 FUTOFFINODE waiter can be requeued onto a FUTOFFMMSHARED futex by another process. This can cause FUTOFFMMSHARED waiters on a freed MM to consume wakeups intended for a newly allocated MM at the same address. Fix it by keying FUTOFFMMSHARED 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 FUTOFFMMSHARED by setting clearchildtid such that it points into anonymous memory, which causes mmrelease() in a multi-threaded mm to perform FUTEXWAKE.)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Key FUT_OFF_MMSHARED futexes using a unique 64-bit per-MM ID, while leaving private futexes unchanged.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected software list includes Ubuntu kernel packages for the standard, realtime, Azure, GCP, Azure FDE, RISC-V, GKE, and AWS kernel variants. The issue concerns shared futex handling, including behavior commonly used by multi-threaded processes through clear_child_tid in anonymous memory.
What conditions are required for the incorrect wakeup behavior?
A FUT_OFF_INODE waiter must be requeued by another process onto a FUT_OFF_MMSHARED futex. After the referenced memory-management structure is freed and a new one is allocated at the same address, stale waiters can consume wakeups intended for the new structure.
How is the issue resolved?
The fix assigns FUT_OFF_MMSHARED futexes a unique 64-bit identifier per memory-management structure, preventing reuse of the same address from matching stale waiters. Private futex handling is unchanged to avoid affecting the hot path.