Description

In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent freeing a timer which is queued on the expiry list Kijo analyzed another race in the POSIX CPU timer code: Commit bf635681c906 converted cpu_timer::firing from a tristate value to a boolean. This lost the distinction between "not owned by the firing list" and "still owned, but delivery was canceled". The resulting race is: expiry handler timer_settime() timer_delete() -------------- --------------- -------------- collect timer onto private firing list firing = true observes firing = true firing = false return TIMER_RETRY wait for handler observes firing = false finish deletion unhash and free timer resume list traversal read freed elist.next -> UAF The firing bit is clearly the wrong indicator since that commit. Check whether the timer is queued on the expiry list or not instead. If it is queued clear the firing bit to prevent signal delivery as before and return TIMER_RETRY so the caller unlocks the timer which allows the expiry code to make progress and remove it from the list.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T09:18:14.737Z",
  "pubdate": "2026-10-06T09:18:14.737Z",
  "executiveSummary": "This vulnerability is a Use-After-Free (UAF) flaw residing in the Linux kernel's POSIX CPU timer subsystem. The issue stems from an improper race condition handling during the timer deletion process, specifically involving the expiry list management.\nThe vulnerability allows for a race condition where a timer object can be freed while still being actively referenced by the kernel's expiry handler. An attacker capable of triggering specific timing sequences between timer_settime(), timer_delete(), and the expiry handler can cause the kernel to access memory that has already been deallocated.\nThis flaw represents a significant risk, as successful exploitation could lead to kernel-level memory corruption, system instability, or potentially arbitrary code execution. The vulnerability is local in nature, requiring the attacker to have the capability to create and manipulate POSIX timers. No remote network exposure is inherently associated with this flaw, as it requires local process interaction with the timer subsystem to trigger the race condition.",
  "technicalDetails": "The root cause of this vulnerability is a design flaw in the cpu_timer management logic, specifically introduced by commit bf635681c906, which transitioned the cpu_timer::firing state from a tristate value to a simple boolean. This simplification obscured the necessary distinction between a timer that is not owned by the firing list and one that is still queued but awaiting cancellation.\nThe attack flow originates from the intersection of the expiry handler, timer_settime(), and timer_delete() system calls. When the kernel's expiry handler collects a timer onto its private firing list, it sets the firing flag to true. A concurrent call to timer_settime() may observe this state, set firing to false, and return TIMER_RETRY. If the timer_delete() function follows, it observes the now false firing flag, concludes that the timer is safe to delete, and proceeds to unhash and free the timer object.\nCrucially, because the firing bit no longer accurately tracks whether the timer remains queued on the expiry list, the expiry handler resumes its list traversal. The handler then attempts to access the elist.next pointer of the object that has just been deallocated by the timer_delete() process, resulting in a Use-After-Free condition.\nExploitation requires precise temporal orchestration of these kernel threads. Because the vulnerability involves the premature freeing of kernel-space objects, an attacker might be able to manipulate heap layout or utilize specialized kernels to gain control over the memory location where the timer structure previously resided. This could permit the redirection of kernel control flow when the expiry handler attempts to reference the corrupted elist.next pointer.\nThe vulnerable component is the kernel's POSIX CPU timer logic, specifically the interaction between expiry list traversal and the timer deletion path. The fix necessitates replacing the reliance on the ambiguous firing bit with a robust check of the timer's actual status within the expiry list. By verifying queue status, the kernel can properly prevent signal delivery and return TIMER_RETRY, ensuring the timer is only freed once it is safely removed from all operational lists, thereby maintaining memory integrity during concurrent operations."
}