UBUNTU-CVE-2026-99144: Use After Free
In the Linux kernel, the following vulnerability has been resolved: schedext: Fix use-after-free of a destroyed user DSQ by a deferred reenqueue A deferred reenqueue can read a freed user DSQ. The request stays on its CPU's deferred list until rundeferred() takes it, and the RCU callback that frees the DSQ assumes that the grace period has flushed it, so exitdsq() checks the per-CPU node without the deferred list lock. A grace period waits for readers in flight, not for a pending rundeferred(). A rundeferred() which starts after the grace period began can detach the request right before the callback looks and then read the freed DSQ's id. Cancel the pending requests before the grace period instead. The irq work that frees the DSQ unlinks every CPU's request under the per-CPU deferred list lock, and scheduledsqreenq() ignores a new request under the same lock once the id is invalid. Only a rundeferred() that started before the grace period can hold a request, and it runs with IRQs disabled, so the grace period waits for it and nothing touches the DSQ after the callback.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Cancel pending run_deferred() requests before beginning the grace period to prevent deferred reenqueue from accessing a destroyed user DSQ.
Event History
Frequently Asked Questions
What conditions are required for the use-after-free to occur?
The issue involves a destroyed user dispatch queue (DSQ) and a deferred reenqueue request that remains on a CPU's deferred list. A race can occur when run_deferred() begins after the RCU grace period has started and accesses the DSQ after its free callback runs.
What mitigation is described if the fix is not yet available?
The provided data does not describe an operational workaround. The resolved approach is to cancel pending deferred reenqueue requests before the RCU grace period, while preventing new requests once the DSQ ID is invalid.
How does the fix prevent later access to a destroyed DSQ?
The DSQ-freeing irq work removes requests from every CPU's deferred list while holding the corresponding deferred-list lock. New reenqueues are ignored under that lock after the DSQ ID becomes invalid, and any already-running deferred handler is covered by the RCU grace period because it runs with interrupts disabled.