CVE-2026-89927: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock
Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall.
Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HVX64MSRSTIMERiCONFIG and HVX64MSRSTIMERiCOUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVMSETMSRS).
When the timer is enabled, stimerstart() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64MAX, the deadline calculation can overflow.
ktimeaddns(ktimenow, 100 (stimer->exptime - timenow))
This can result in a CPU livelock. stimerstart() arms the timer via hrtimerstart() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVMRQHVSTIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter.
Then, once userspace issues KVMRUN, vcpuenterguest() consumes the request, calling kvmhvprocessstimers(). This would normally disable the timer via stimerexpiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exptime, which is a big value close to U64MAX, so this never happens for a few thousand years.
kvmhvprocesstimers() then re-arms the timer via stimerstart(), since it was not disabled, which again fires immediately. Before entering the guest, kvmvcpuexitrequest() checks kvmrequestpending(), which returns true due to the newly raised KVMREQHVSTIMER. Then vcpuenterguest() aborts the guest entry, returning early into vcpurun(), which loops back again into vcpuenterguest(), restarting the cycle.
Since there are no manual yields in this loop, a task with SCHEDFIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller:
rcu: INFO: rcupreempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcupreempt kthread activity 10500 (4294965239-4294954739), jiffiestillnextfqs=1, root ->qsmask 0x0 rcu: rcupreempt kthread starved for 10500 jiffies! g14269 f0x2 RCUGPWAITFQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcupreempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: <IRQ> runhrtimer kernel/time/hrtimer.c:1773 [inline] hrtimerrunqueues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimerinterrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 localapictimerinterrupt arch/x86/kernel/apic/apic.c:1045 [inline] sysvecapictimerinterrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvecapictimerinterrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:rawspinunlockirqrestore include/linux/spinlockapismp.h:152 [inline] RIP: 0010:rawspinunlockirqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 <e8> 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
KVM: x86: hyper-vto a version that resolves this vulnerability.Patch Clamp stimer deadline to avoid livelock - Compensating control
If you cannot immediately apply the kernel fix, mitigate the livelock risk by restricting/controlling guest or userspace ability to program Hyper-V synthetic timer MSRs HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT (e.g., limit which guests/users can use KVM_SET_MSRS or WRMSR to those MSRs).
Event History
Frequently Asked Questions
Who can trigger the condition?
A guest can program one of its Hyper-V synthetic timers through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Host userspace can also set these timer MSRs through KVM_SET_MSRS.
What configuration is required for exposure?
The affected functionality is KVM's emulation of Hyper-V SynIC synthetic timers. SynIC provides four synthetic timers per vCPU, and the issue occurs when a timer is enabled with a COUNT value close to U64_MAX.
What happens when exploitation succeeds?
An integer overflow can produce a monotonic timer deadline in the past. The hrtimer then fires immediately and can repeatedly trigger KVM_RQ_HV_STIMER, preventing CPU progress and causing an RCU stall.
Is the timer mode relevant?
Yes. Depending on the timer configuration, COUNT is interpreted as either an absolute expiration time or the period for a periodic timer, in 100-nanosecond ticks; both modes use the vulnerable deadline conversion when the timer starts.