CVE-2026-74594

Status: UPDATED  |  Advisory ID: CVE-2026-74594

Key Details

Affected Products, Subsystems & Sectors

What to Know

In the Linux kernel, the following vulnerability has been resolved:

sched/psi: Shut down rtpoll_timer in psi_cgroup_free()

psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath

and can race psi_trigger_destroy() taking down the last rtpoll trigger under

rtpoll_trigger_lock:

psi_schedule_rtpoll_work() psi_trigger_destroy()

rcu_read_lock();

task = rcu_dereference(rtpoll_task);

rcu_assign_pointer(rtpoll_task, NULL);

timer_delete(&rtpoll_timer);

mod_timer(&rtpoll_timer, ...);

rcu_read_unlock();

synchronize_rcu();

kthread_stop(task_to_destroy);

The group can then be freed with the re-armed timer still pending, and

poll_timer_fn() runs on freed memory.

461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling

mechanism") deleted the timer synchronously after the synchronize_rcu(),

which prevented this but raced trigger creation instead: the deletion could

cancel the timer that a new trigger set armed during the grace period and,

as creation also reinitialized the timer at the time, corrupt it.

8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the

initialization into group_init() and the deletion into the locked section,

trading the creation races for the window above.

Neither placement in the destruction path works. A pending timer firing

while the group is alive is harmless though. poll_timer_fn() just wakes the

rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's

lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it

by then. timer_shutdown_sync() because the timer is never armed again. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References