CVE-2025-68202: sched_ext: Fix unsafe locking in the scx_dump_state()
In the Linux kernel, the following vulnerability has been resolved:
schedext: Fix unsafe locking in the scxdumpstate()
For built with CONFIGPREEMPTRT=y kernels, the dumplock will be converted sleepable spinlock and not disable-irq, so the following scenarios occur:
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. irqwork/0/27 [HC0[0]:SC0[0]:HE1:SE1] takes: (&rq->lock){?...}-{2:2}, at: rawspinrqlocknested+0x2b/0x40 {IN-HARDIRQ-W} state was registered at: lockacquire+0x1e1/0x510 rawspinlocknested+0x42/0x80 rawspinrqlocknested+0x2b/0x40 schedtick+0xae/0x7b0 updateprocesstimes+0x14c/0x1b0 tickperiodic+0x62/0x1f0 tickhandleperiodic+0x48/0xf0 timerinterrupt+0x55/0x80 handleirqeventpercpu+0x20a/0x5c0 handleirqeventpercpu+0x18/0xc0 handleirqevent+0xb5/0x150 handlelevelirq+0x220/0x460 commoninterrupt+0xa2/0x1e0 commoninterrupt+0xb0/0xd0 asmcommoninterrupt+0x2b/0x40 rawspinunlockirqrestore+0x45/0x80 setupirq+0xc34/0x1a30 requestthreadedirq+0x214/0x2f0 hpettimeinit+0x3e/0x60 x86latetimeinit+0x5b/0xb0 startkernel+0x308/0x410 x8664startreservations+0x1c/0x30 x8664startkernel+0x96/0xa0 commonstartup64+0x13e/0x148
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(&rq->lock); <Interrupt> lock(&rq->lock);
DEADLOCK
stack backtrace: CPU: 0 UID: 0 PID: 27 Comm: irqwork/0 Call Trace: <TASK> dumpstacklvl+0x8c/0xd0 dumpstack+0x14/0x20 printusagebug+0x42e/0x690 marklock.part.44+0x867/0xa70 ? pfxmarklock.part.44+0x10/0x10 ? stringnocheck+0x19c/0x310 ? number+0x739/0x9f0 ? pfxstringnocheck+0x10/0x10 ? pfxcheckpointer+0x10/0x10 ? kvmschedclockread+0x15/0x30 ? schedclocknoinstr+0xd/0x20 ? localclocknoinstr+0x1c/0xe0 lockacquire+0xc4b/0x62b0 ? pfxformatdecode+0x10/0x10 ? pfxstring+0x10/0x10 ? pfxlockacquire+0x10/0x10 ? pfxvsnprintf+0x10/0x10 lockacquire+0x1e1/0x510 ? rawspinrqlocknested+0x2b/0x40 ? pfxlockacquire+0x10/0x10 ? dumpline+0x12e/0x270 ? rawspinrqlocknested+0x20/0x40 rawspinlocknested+0x42/0x80 ? rawspinrqlocknested+0x2b/0x40 rawspinrqlocknested+0x2b/0x40 scxdumpstate+0x3b3/0x1270 ? finishtaskswitch+0x27e/0x840 scxopserrorirqworkfn+0x67/0x80 irqworksingle+0x113/0x260 irqworkrunlist.part.3+0x44/0x70 runirqworkd+0x6b/0x90 ? pfxrunirqworkd+0x10/0x10 smpbootthreadfn+0x529/0x870 ? pfxsmpbootthreadfn+0x10/0x10 kthread+0x305/0x3f0 ? pfxkthread+0x10/0x10 retfromfork+0x40/0x70 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
This commit therefore use rqlockirqsave/irqrestore() to replace rqlock/unlock() in the scxdumpstate().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In scx_dump_state(), replace rq_lock()/rq_unlock() with rq_lock_irqsave()/rq_unlock_irqrestore() to disable and restore interrupts while locking the run queue, including for CONFIG_PREEMPT_RT=y kernels.
Event History
Frequently Asked Questions
What is the severity of CVE-2025-68202?
CVE-2025-68202 has been classified as a medium severity vulnerability in the Linux kernel.
How do I fix CVE-2025-68202?
To fix CVE-2025-68202, update your Linux kernel to a version that includes the patch addressing this vulnerability.
Which versions of the Linux kernel are affected by CVE-2025-68202?
CVE-2025-68202 affects Linux kernel versions built with CONFIG_PREEMPT_RT=y.
What type of vulnerability is CVE-2025-68202?
CVE-2025-68202 is a locking and synchronization vulnerability in the Linux kernel's scheduler.
Is there a known exploit for CVE-2025-68202?
As of now, there are no known exploits publicly available for CVE-2025-68202.