CVE-2026-74749 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
rseq: Prevent hard lockup on granted time slice extension
__exit_to_user_mode_loop() invokes rseq_grant_timeslice_extension() with interrupts enabled. If the extension is granted it invokes hrtimer_rearm_deferred_tif() to ensure that a pending deferred hrtimer rearm is handled before exiting to user space.
Though this invokes __hrtimer_rearm_deferred() which expects to be invoked with interrupts disabled as it takes hrtimer_cpu_base::lock with raw_spin_lock(). That's a livelock waiting to happen and caught by lockdep:
WARNING: ./include/linux/hrtimer_rearm.h:17 at irqentry_exit, CPU#1: slice_test WARNING: inconsistent lock state inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
Prevent this by disabling interrupts around the invocation of hrtimer_rearm_deferred_tif() in rseq_grant_timeslice_extension().
[ tglx: Massaged change log ]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel's restartable sequences (rseq) subsystem is designed to provide efficient, lock-free per-CPU state management for user-space threads. A critical concurrency flaw was identified in the implementation of time slice extension logic within this subsystem, specifically involving the interaction between interrupt handling and timer rearming mechanisms. The vulnerability arises when __exit_to_user_mode_loop invokes rseq_grant_timeslice_extension while interrupts are enabled. If a timeslice extension is granted, the code path proceeds to call hrtimer_rearm_deferred_tif() to ensure that any pending deferred high-resolution timer (hrtimer) rearming operations are processed before returning control to user space. This sequence creates a dangerous race condition because the underlying function __hrtimer_rearm_deferred expects interrupts to be disabled, as it acquires hrtimer_cpu_base::lock using raw_spin_lock().
The use of raw_spin_lock in an interrupt-enabled context is fundamentally unsafe on architectures where softirqs or hard IRQs can preempt the current execution flow. When interrupts are enabled during this critical section, a concurrent hardware interrupt may attempt to acquire the same lock, leading to a livelock scenario. This condition was detected by kernel developers using Lockdep, which reported an inconsistent lock state warning indicating that code marked as requiring interrupts disabled (IN-HARDIRQ-W) was being executed with interrupts on (HARDIRQ-ON-W). Such inconsistencies can lead to hard lockups where the CPU becomes unresponsive due to circular dependencies or repeated failed lock acquisitions.
From a security and stability perspective, this vulnerability represents a denial of service risk through resource exhaustion and system hang conditions. An attacker who can trigger frequent context switches combined with specific timer events might exacerbate the likelihood of encountering this race condition, although it is primarily an instability issue rather than a direct privilege escalation vector. The flaw aligns with CWE-662, which describes improper synchronization mechanisms that lead to race conditions and deadlocks in concurrent systems. Additionally, the behavior relates to ATT&CK technique T1499, specifically endpoint denial of service via resource exhaustion or loop-based attacks, as the livelock effectively halts normal system operations on the affected CPU core.
The resolution involves modifying rseq_grant_timeslice_extension to disable interrupts around the invocation of hrtimer_rearm_deferred_tif(). This ensures that the critical section protected by raw_spin_lock is executed in a context where preemption and interrupt handling are suspended, thereby preventing concurrent access attempts that cause the livelock. Mitigation strategies for system administrators include applying kernel updates that incorporate this fix to restore stable timer management during user-mode exit transitions. For developers maintaining custom kernels or embedded systems relying on rseq optimizations, verifying that all lock acquisitions in high-frequency code paths respect interrupt state requirements is essential to prevent similar synchronization failures.