Linux kernel RT scheduler: push_rt_task race corrupts runqueue state and panics the host

CVSS 4.7CVE-2025-38234Kernel, userspace & hypervisorcurated

Impact

push_rt_task() drops and re-acquires the runqueue locks in find_lock_lowest_rq(). In the window, a task can migrate away, finish, and be woken again onto the same CPU, so the existing re-validation checks pass even though the task is no longer on the pushable list. The reported result is a family of kernel panics from inside the scheduler itself - BUG_ON(idx >= MAX_RT_PRIO), BUG_ON(!rq->nr_running), NULL pointer dereferences and runqueue corruption - with no single recognisable signature. Operators who use SCHED_FIFO/SCHED_RR for latency-sensitive inference serving, data-plane threads or MPI ranks are the ones exposed; a node that crashes this way looks like flaky hardware and burns time to diagnose. Nodes not using real-time scheduling classes are not affected.

Who can reach it

Local. Requires workloads running in the RT scheduling classes on a multi-CPU host; triggering it deliberately needs the ability to create RT-priority tasks, which normally means root or CAP_SYS_NICE. In practice this fires as an accident, not an attack.

What to do

Patch the kernel to a stable release containing the linked push_rt_task fix and reboot each node; the race is in core scheduler code with no tunable or module to disable. Where patching must wait, moving latency-sensitive threads off SCHED_FIFO/SCHED_RR removes the exposure. The record lists stable commits but no named fixed version.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-38234 https://git.kernel.org/stable/c/07ecabfbca64f4f0b6071cf96e49d162fa9d138d https://git.kernel.org/stable/c/debfbc047196df1f6bfd52f2d028c21dce67f0de

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.