CVE-2026-98258 in Linux
Summary
by MITRE • 10/06/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel contains a race condition within the POSIX CPU timer subsystem that can lead to use-after-free vulnerabilities, posing significant risks to system stability and security. This flaw was identified by Kijo as a regression introduced in commit bf635681c906, which refactored the cpu_timer structure by converting the firing field from a tristate value to a simple boolean. While this change simplified the code logic, it inadvertently eliminated the critical distinction between timers that are not owned by the firing list and those that remain owned but have had their delivery canceled. This loss of state granularity created an opportunity for concurrent operations to interfere with each other in unsafe ways during timer expiration handling.
The operational mechanism of the vulnerability involves a specific sequence of events where multiple threads interact with the same POSIX CPU timer object simultaneously. An expiry handler may collect a timer onto its private firing list and set the firing flag to true, indicating that delivery is in progress. Concurrently, an application thread might invoke timer_settime or timer_delete operations. If timer_delete is called while the expiry handler has observed the firing bit as true but before it completes processing, the deletion logic may proceed under the assumption that no active handling is occurring. The deletion routine observes the firing state and proceeds to unhash and free the timer structure from memory. However, because the expiry handler still holds a reference or pointer to this now-freed object, subsequent operations such as resuming list traversal can result in reading freed memory via elist.next pointers. This classic use-after-free scenario allows for potential arbitrary code execution if an attacker can control the contents of the reclaimed memory region before it is reallocated and repurposed by other kernel subsystems.
From a technical perspective, this vulnerability aligns with CWE-416, which describes Use After Free conditions where software continues to use memory after it has been freed, leading to undefined behavior or security breaches. The root cause lies in the improper synchronization of state transitions within the timer management code. By relying solely on the firing boolean bit as an indicator for whether a timer is currently being processed, the kernel failed to account for timers that are queued but whose delivery was subsequently canceled by user-space requests. This oversight meant that the expiry handler did not properly check if the timer remained validly queued on the global expiry list before proceeding with signal delivery or memory access operations. The lack of robust state verification allowed the race condition to manifest, where one thread frees resources while another continues to operate on them based on stale assumptions about their lifecycle status.
The impact of this vulnerability extends beyond simple crashes; it represents a serious security risk that can be exploited for privilege escalation or denial of service attacks. An attacker with local access could potentially trigger these race conditions by rapidly creating and deleting POSIX CPU timers while monitoring system behavior, aiming to corrupt kernel memory structures. Successful exploitation could allow the execution of arbitrary code within the context of the kernel, granting full control over the affected system. Furthermore, even without successful exploitation for code execution, the instability caused by use-after-free bugs can lead to unpredictable system crashes, affecting availability and reliability for all users on the host machine.
To mitigate this vulnerability, developers must ensure that timer deletion logic correctly verifies whether a timer is still queued on the expiry list before proceeding with deallocation. The fix involves checking the queue status rather than relying solely on the firing bit state. If a timer is found to be queued despite cancellation attempts, the firing bit should be cleared to prevent signal delivery, and the operation should return TIMER_RETRY. This approach ensures that the caller unlocks the timer appropriately, allowing the expiry code to make progress and safely remove it from the list without risking premature memory release. Implementing these checks restores the necessary synchronization between user-space timer management calls and kernel-side expiration handling routines.
Security practitioners and system administrators should apply the latest available patches for their Linux distributions immediately to address this issue. Regular updates are essential as they incorporate fixes for such low-level concurrency bugs that are difficult to detect through standard application testing alone. Additionally, organizations employing static analysis tools or fuzzing techniques on kernel components can help identify similar race conditions in other subsystems before they reach production environments. Monitoring system logs for unexpected crashes related to timer operations may also provide early indicators of attempted exploitation attempts against unpatched systems.