Look up another CVE · open CVE-2026-89927 in the interactive tracker
CVE-2026-89927
KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem arch/x86. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89927 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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---
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/x86/kvm/hyperv.c
- What this is
- KVM X86 HYPER-V (KVM/hyper-v)MAINTAINERS section matched on arch/x86/kvm/hyperv.* · kvm@vger.kernel.org · Supported
- Kernel module
- kvm
Check it on the machine
grep -wE 'CONFIG_KVM|CONFIG_KVM_HYPERV|CONFIG_KVM_X86' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w kvmPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormBnot built on arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- trixieMnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- bookworm · linux-6.12Mnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
- B
- built in on some, a module on others, absent on the rest
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_KVM, CONFIG_KVM_HYPERV, CONFIG_KVM_X86
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/x86
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.5 | 5.10.270 | a46657623887 |
| 4.5 | 5.15.221 | 61954727ee08 |
| 4.5 | 6.1.188 | 8aa467fe757d |
| 4.5 | 6.6.157 | 8e19ded84336 |
| 4.5 | 6.12.110 | 6a8ba9213cce |
| 4.5 | 6.18.51 | 3097582b73a8 |
| 4.5 | 7.2.5 | bdb732ebee54 |
| 4.5 | 7.3 | 0ca49fbd2883 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Guest WRMSR to HV_X64_MSR_STIMERi_CONFIG/COUNT is trapped into KVM (kvm_emulate_wrmsr -> kvm_hv_set_msr_common -> stimer_set_config/count); host userspace can also program the same MSRs via KVM_SET_MSRS, then KVM_RUN. Both paths are local KVM VM-exit/ioctl, not network, adjacent-radio, or physical.
- AC:LAttack complexity, low
- The attacker fully controls COUNT/CONFIG. A one-shot COUNT near U64_MAX deterministically overflows 100*(exp_time-time_now), so hrtimer_start() uses a past deadline and kvm_hv_process_stimers() re-arms forever. CONFIG_KVM_HYPERV defaults to Y and hv-synic/hv-stimer are standard on Windows KVM guests; no race or rare config is required.
- PR:NPrivileges required, none
- The highest-impact case is a cloud x86 KVM tenant whose VM already has Hyper-V CPUID and KVM_CAP_HYPERV_SYNIC (normal for Windows/hv-stimer guests). They WRMSR the stimer MSRs from guest CPL0 with no host root, init-namespace capability, or /dev/kvm access.
- UI:NUser interaction, none
- The guest programs the synthetic timer during ordinary KVM_RUN; the host vCPU thread livelocks on the same vcpu_enter_guest path with no additional victim action such as mounting a filesystem or opening a file.
- S:CScope, changed
- The retry loop runs in the host KVM vCPU thread (vcpu_run/vcpu_enter_guest) and can stall host CPUs, starve RCU, and OOM the machine, taking down the hypervisor and co-resident VMs and crossing the KVM guest-to-host security boundary.
- C:NConfidentiality impact, none
- This is an integer overflow in the stimer deadline calculation that only mis-arms an hrtimer; there is no out-of-bounds read, use-after-free, or other host memory disclosure primitive.
- I:NIntegrity impact, none
- Host kernel memory is not written or corrupted; the overflowed deadline only produces a KVM_REQ_HV_STIMER/hrtimer retry loop with no arbitrary write or control-flow hijack.
- A:HAvailability impact, high
- stimer_start() re-arms an immediately expiring hrtimer, kvm_vcpu_exit_request() aborts VM-entry, and vcpu_run() loops without a dedicated yield, livelocking the host vCPU thread. A SCHED_FIFO VMM can starve RCU (syzkaller RCU stall and expected OOM), denying service to the host and co-located VMs.