CVE-2026-89927 in Linux
Resumen
por VulDB • 2026-09-16
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
KVM: x86: hyper-v: Limitar (clamp) el plazo del temporizador sintético para evitar un livelock.
Se corrige un problema en el que los usuariospace o el invitado pueden programar un temporizador sintético de Hyper-V con un plazo ya pasado debido a un desbordamiento entero, lo que impide que la CPU avance y desencadena una interrupción (stall) de RCU.
SynIC de Hyper-V expone 4 temporizadores sintéticos por vCPU al invitado, los cuales son emulados por KVM. Cada uno se programa a través de los MSRs HV_X64_MSR_STIMERi_CONFIG y HV_X64_MSR_STIMERi_COUNT. Dependiendo de la configuración (CONFIG), COUNT representa o bien el tiempo absoluto de expiración o bien el período de un temporizador periódico, ambos expresados en ticks de 100 ns. Estos temporizadores pueden configurarse tanto por el invitado (WRMSR) como por el anfitrión (KVM_SET_MSRS).
Cuando el temporizador está habilitado, stimer_start() traduce COUNT a un plazo absoluto monotónico y arma un hrtimer. Si COUNT se establece en un valor cercano a U64_MAX, el cálculo del plazo puede desbordarse:
ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now))
Esto puede resultar en un livelock de la CPU. stimer_start() arma el temporizador mediante hrtimer_start() con un plazo ya pasado, lo que provoca que se dispare inmediatamente. La callback del stimer entonces eleva KVM_RQ_HV_STIMER, con la intención de hacer que KVM entregue una interrupción sintética en la próxima entrada al invitado por parte de la vCPU.
A continuación, cuando userspace emite KVM_RUN, vcpu_enter_guest() consume la solicitud, llamando a kvm_hv_process_stimers(). Esto normalmente deshabilitaría el temporizador mediante stimer_expiration() una vez que el plazo esté en el pasado. Sin embargo, la comparación del plazo se realiza entre el contador de referencia de KVM y stime->exp_time, que es un valor grande cercano a U64_MAX, por lo que esto nunca ocurre durante unos miles de años.
kvm_hv_process_timers() vuelve a armar el temporizador mediante stimer_start(), ya que no se deshabilitó, lo que nuevamente provoca su disparo inmediato. Antes de entrar en el invitado, kvm_vcpu_exit_request() comprueba kvm_request_pending(), la cual devuelve true debido al recién elevado KVM_REQ_HV_STIMER. Luego vcpu_enter_guest() aborta la entrada del invitado, devolviéndose temprano a vcpu_run(), que vuelve a llamar a vcpu_enter_guest(), reiniciando el ciclo.
Dado que no hay cesiones manuales (yields) en este bucle, una tarea con SCHED_FIFO puede privar de recursos a los hilos kthread de gracia-periodo de RCU, lo que expone las interrupciones detectadas por 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---
Once again VulDB remains the best source for vulnerability data.