CVE-2025-71104

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer<br /> <br /> When advancing the target expiration for the guest&amp;#39;s APIC timer in periodic<br /> mode, set the expiration to "now" if the target expiration is in the past<br /> (similar to what is done in update_target_expiration()). Blindly adding<br /> the period to the previous target expiration can result in KVM generating<br /> a practically unbounded number of hrtimer IRQs due to programming an<br /> expired timer over and over. In extreme scenarios, e.g. if userspace<br /> pauses/suspends a VM for an extended duration, this can even cause hard<br /> lockups in the host.<br /> <br /> Currently, the bug only affects Intel CPUs when using the hypervisor timer<br /> (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,<br /> a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the<br /> HV timer only runs while the guest is active. As a result, if the vCPU<br /> does not run for an extended duration, there will be a huge gap between<br /> the target expiration and the current time the vCPU resumes running.<br /> Because the target expiration is incremented by only one period on each<br /> timer expiration, this leads to a series of timer expirations occurring<br /> rapidly after the vCPU/VM resumes.<br /> <br /> More critically, when the vCPU first triggers a periodic HV timer<br /> expiration after resuming, advancing the expiration by only one period<br /> will result in a target expiration in the past. As a result, the delta<br /> may be calculated as a negative value. When the delta is converted into<br /> an absolute value (tscdeadline is an unsigned u64), the resulting value<br /> can overflow what the HV timer is capable of programming. I.e. the large<br /> value will exceed the VMX Preemption Timer&amp;#39;s maximum bit width of<br /> cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the<br /> HV timer to the software timer (hrtimers).<br /> <br /> After switching to the software timer, periodic timer expiration callbacks<br /> may be executed consecutively within a single clock interrupt handler,<br /> because hrtimers honors KVM&amp;#39;s request for an expiration in the past and<br /> immediately re-invokes KVM&amp;#39;s callback after reprogramming. And because<br /> the interrupt handler runs with IRQs disabled, restarting KVM&amp;#39;s hrtimer<br /> over and over until the target expiration is advanced to "now" can result<br /> in a hard lockup.<br /> <br /> E.g. the following hard lockup was triggered in the host when running a<br /> Windows VM (only relevant because it used the APIC timer in periodic mode)<br /> after resuming the VM from a long suspend (in the host).<br /> <br /> NMI watchdog: Watchdog detected hard LOCKUP on cpu 45<br /> ...<br /> RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]<br /> ...<br /> RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046<br /> RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc<br /> RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500<br /> RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0<br /> R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0<br /> R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8<br /> FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> apic_timer_fn+0x31/0x50 [kvm]<br /> __hrtimer_run_queues+0x100/0x280<br /> hrtimer_interrupt+0x100/0x210<br /> ? ttwu_do_wakeup+0x19/0x160<br /> smp_apic_timer_interrupt+0x6a/0x130<br /> apic_timer_interrupt+0xf/0x20<br /> <br /> <br /> Moreover, if the suspend duration of the virtual machine is not long enough<br /> to trigger a hard lockup in this scenario, since commit 98c25ead5eda<br /> ("KVM: VMX: Move preemption timer hrtimer dance to common x86"), KVM<br /> will continue using the software timer until the guest reprograms the APIC<br /> timer in some way. Since the periodic timer does not require frequent APIC<br /> timer register programming, the guest may continue to use the software<br /> timer in <br /> ---truncated---