From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6612B50AC15 for ; Wed, 16 Sep 2026 10:39:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789555205; cv=none; b=FPIX86oFMxUYYwd/ZYjQR8sHcbWJtiD7ORoOwrClECFY2IFf6BMoZNd7XYwgzprJ1zMCslifhkb/z6PjC8DgVP6l8TZBCESOvfeIZ0PKKfHYjWyiPecrL13Hr/ylLB2ex5NgRv8aZWLBuL6BtqpJhSjRvKqvOGnNKBsXojmyCqg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789555205; c=relaxed/simple; bh=TYeoGvUMGEuo9Ed63vVXfGuKXhvAQ3OmxKFqyffSy8U=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=LdLYyFeSZZUklnc6fSq8flwTMDYB50ftXVp45gHjpxHnSNwOouq/FXd++cYUQbyQ/fTLVte8t+UpS5v2UsLNnpwFngFoUuSSM4istLB/l1R4hXd1zLhpG8XbOK59EkfQ9TcHYXl0+7Av2PpCOsqUujhRt1vdwvejGbA06KCp8zc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=PWH/PEa0; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="PWH/PEa0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5A7C1F0089A; Wed, 16 Sep 2026 10:39:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1789555187; bh=ie9oL3MUm1WRB87twrWpkmW1Ca/HC4rrcGJlW/0BXzA=; h=From:To:Cc:Subject:Date:Reply-To; b=PWH/PEa0jgNjR8yZYndfUJ+LK5NWSuMvheSd3w88fhiudojWRZBWxcUD5+c63OI1w 634eVEzY+eYmbaXYNaJ81zZx6yw7iNvQYnkXOLUfTkmBvmVPb/T5DxrJKR+vDn6jTu GlgAMWw7291HAZRyAWNJAAObwa0YGmhWFUezCGp0= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-89927: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Date: Wed, 16 Sep 2026 11:30:57 +0100 Message-ID: <2026091644-CVE-2026-89927-fd90@gregkh> X-Mailer: git-send-email 2.55.0 Reply-To: , Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=8926; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=UZvcKgzFCPf4rvjO08l5Cgm+ncCCRqv41GFH5Aa6H9k=; b=owGbwMvMwCRo6H6F97bub03G02pJDFmr8me84T3plaGt6vZZKed5mUvk5XM+0U1BOfwH42auK Hz3stC+I5aFQZCJQVZMkeXLNp6j+ysOKXoZ2p6GmcPKBDKEgYtTACbiW8owV+BEliZHZ+8535n7 9z4tsH+xKLvUhGGepUnNJolFzTfN30xaInb+lpBrfaQ0AA== X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman 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: __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 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 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 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