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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

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: ffffffff8fc3d077 R09: 1ffffffff1f87a0e
    R10: dffffc0000000000 R11: fffffbfff1f87a0f R12: dffffc0000000000
    R13: 0000000000000000 R14: ffff8880b8628240 R15: 1ffff92000814e64
     hrtimer_start include/linux/hrtimer.h:259 [inline]
     stimer_start arch/x86/kvm/hyperv.c:682 [inline]
     kvm_hv_process_stimers+0xd0a/0x16a0 arch/x86/kvm/hyperv.c:893
     vcpu_enter_guest arch/x86/kvm/x86.c:11193 [inline]
     vcpu_run+0x2240/0x76b0 arch/x86/kvm/x86.c:11639
     kvm_arch_vcpu_ioctl_run+0x1148/0x1c90 arch/x86/kvm/x86.c:11984
     kvm_vcpu_ioctl+0x99a/0xed0 virt/kvm/kvm_main.c:4492
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:597 [inline]
     __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f635278f749
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f635365c038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007f63529e5fa0 RCX: 00007f635278f749
    RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005
    RBP: 00007f6352813f91 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007f63529e6038 R14: 00007f63529e5fa0 R15: 00007ffd5b219358
     </TASK>

Fix this by clamping the deadline computation to KTIME_MAX, which
preserves the intent of arming a timer very far in the future.
ktime_add_safe() already does this type of clamping, so use it after
checking that that multiplying by the 100ns time tick also does not
overflow.

[sean: tag for stable]

The Linux kernel CVE team has assigned CVE-2026-89927 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.5 with commit 1f4b34f825e8cef6f493d06b46605384785b3d16 and fixed in 5.10.270 with commit a4665762388750e08df99baabe5fce2a21d1423e
	Issue introduced in 4.5 with commit 1f4b34f825e8cef6f493d06b46605384785b3d16 and fixed in 5.15.221 with commit 61954727ee08f026f5e1c9ee69e1b404a68f2f7a
	Issue introduced in 4.5 with commit 1f4b34f825e8cef6f493d06b46605384785b3d16 and fixed in 6.1.188 with commit 8aa467fe757d8cb2278e98d7fbf44fc05eb0dbf8
	Issue introduced in 4.5 with commit 1f4b34f825e8cef6f493d06b46605384785b3d16 and fixed in 6.6.157 with commit 8e19ded84336891646b31375720717635f0fdd90
	Issue introduced in 4.5 with commit 1f4b34f825e8cef6f493d06b46605384785b3d16 and fixed in 6.12.110 with commit 6a8ba9213cce613455b1502ee0fd178656bf617b
	Issue introduced in 4.5 with commit 1f4b34f825e8cef6f493d06b46605384785b3d16 and fixed in 6.18.51 with commit 3097582b73a8ed1cd6f6790fa78706f4a79b5a49
	Issue introduced in 4.5 with commit 1f4b34f825e8cef6f493d06b46605384785b3d16 and fixed in 7.2.5 with commit bdb732ebee545b7e3bee7060efc754a8d99818b9
	Issue introduced in 4.5 with commit 1f4b34f825e8cef6f493d06b46605384785b3d16 and fixed in 7.3-rc1 with commit 0ca49fbd2883cd53d32d85b50feef17fa04d0fbf

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-89927
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	arch/x86/kvm/hyperv.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	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