CVE-2026-74749: rseq: Prevent hard lockup on granted time slice extension
In the Linux kernel, the following vulnerability has been resolved:
rseq: Prevent hard lockup on granted time slice extension
exittousermodeloop() invokes rseqgranttimesliceextension() with interrupts enabled. If the extension is granted it invokes hrtimerrearmdeferredtif() to ensure that a pending deferred hrtimer rearm is handled before exiting to user space.
Though this invokes hrtimerrearmdeferred() which expects to be invoked with interrupts disabled as it takes hrtimercpubase::lock with rawspinlock(). That's a livelock waiting to happen and caught by lockdep:
WARNING: ./include/linux/hrtimerrearm.h:17 at irqentryexit, CPU#1: slicetest WARNING: inconsistent lock state inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
Prevent this by disabling interrupts around the invocation of hrtimerrearmdeferredtif() in rseqgranttimesliceextension().
[ tglx: Massaged change log ]
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the lockup?
The issue requires a granted rseq time-slice extension while exiting to user mode, with a pending deferred hrtimer rearm that is handled through hrtimer_rearm_deferred_tif(). The problematic path takes the hrtimer CPU-base raw spinlock with interrupts enabled, contrary to the lock's expected interrupt state.
What is the operational impact?
The affected path can enter a livelock and cause a hard lockup. Lockdep can report this as inconsistent lock-state usage, transitioning from IN-HARDIRQ-W to HARDIRQ-ON-W at irqentry_exit.
How can I determine whether the fix is present?
Check whether your kernel includes either referenced stable commit: 8bbf4405050bc4f98be68082a20efa081ea8ad9b or ada54c2ba652348c590d1ace6a2f4ff77cbbf809. The fix disables interrupts around the call to hrtimer_rearm_deferred_tif() in rseq_grant_timeslice_extension().