CVE-2026-74594

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/psi: Shut down rtpoll_timer in psi_cgroup_free()<br /> <br /> psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath<br /> and can race psi_trigger_destroy() taking down the last rtpoll trigger under<br /> rtpoll_trigger_lock:<br /> <br /> psi_schedule_rtpoll_work() psi_trigger_destroy()<br /> <br /> rcu_read_lock();<br /> task = rcu_dereference(rtpoll_task);<br /> rcu_assign_pointer(rtpoll_task, NULL);<br /> timer_delete(&amp;rtpoll_timer);<br /> mod_timer(&amp;rtpoll_timer, ...);<br /> rcu_read_unlock();<br /> synchronize_rcu();<br /> kthread_stop(task_to_destroy);<br /> <br /> The group can then be freed with the re-armed timer still pending, and<br /> poll_timer_fn() runs on freed memory.<br /> <br /> 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling<br /> mechanism") deleted the timer synchronously after the synchronize_rcu(),<br /> which prevented this but raced trigger creation instead: the deletion could<br /> cancel the timer that a new trigger set armed during the grace period and,<br /> as creation also reinitialized the timer at the time, corrupt it.<br /> 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the<br /> initialization into group_init() and the deletion into the locked section,<br /> trading the creation races for the window above.<br /> <br /> Neither placement in the destruction path works. A pending timer firing<br /> while the group is alive is harmless though. poll_timer_fn() just wakes the<br /> rtpoll waitqueue and doesn&amp;#39;t re-arm itself. Bind the timer to the group&amp;#39;s<br /> lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it<br /> by then. timer_shutdown_sync() because the timer is never armed again.