Odebrany

CVE-2026-89927

opublikowano: 16.09.2026, 13:17

modyfikacja: 16.09.2026, 17:18

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

KVM: x86: hyper-v: Ostateczny termin timera zacisku, aby uniknąć blokady na żywo

Napraw problem polegający na tym, że przestrzeń użytkownika lub gość może zaprogramować Hyper-V
timer syntetyczny, aby mieć termin w przeszłości poprzez przepełnienie liczb całkowitych,
uniemożliwiając procesorowi postęp i powodując zatrzymanie RCU.

SynIC Hyper-V udostępnia 4 syntetyczne timery na każdy vCPU
gościa, które są emulowane przez KVM. Każdy jest programowany poprzez
HV_X64_MSR_STIMERi_CONFIG i HV_X64_MSR_STIMERi_COUNT MSR. W zależności
w CONFIG, COUNT reprezentuje albo bezwzględny czas wygaśnięcia, albo
okres licznika okresowego, oba wyrażone w odstępach co 100 ns. Te timery
może być ustawiony zarówno przez gościa (WRMSR), jak i hosta (KVM_SET_MSRS).

Gdy timer jest włączony, timer_start() tłumaczy COUNT na
absolutnie monotonny termin i broń hrtimera. Jeśli COUNT jest ustawione na a
wartość bliska U64_MAX, kalkulacja terminu może zostać przekroczona.

ktime_add_ns(ktime_now, 100 * (timer->exp_time - time_now))

Może to spowodować blokadę procesora. timer_start() uzbraja timer
poprzez hrtimer_start() z ostatecznym terminem w przeszłości, co powoduje, że tak jest
natychmiast odpalić. Następnie wywołanie zwrotne timera podnosi KVM_RQ_HV_STIMER, za pomocą
zamiar spowodowania, aby KVM dostarczył syntetyczne przerwanie na serwerze
wejście następnego gościa vCPU.

Następnie, gdy przestrzeń użytkownika wyda KVM_RUN, vcpu_enter_guest() zużywa
żądanie, wywołując kvm_hv_process_stimers(). Zwykle powoduje to wyłączenie
timer za pomocą stimer_expiration(), gdy termin minie w przeszłości.
Jednak porównanie terminów odbywa się pomiędzy referencjami KVM
licznik i stime->exp_time, co jest dużą wartością bliską U64_MAX, więc
coś takiego nie zdarza się nigdy przez kilka tysięcy lat.

kvm_hv_process_timers() następnie ponownie uzbraja timer poprzez stimer_start(), ponieważ
nie został wyłączony, co ponownie uruchamia się natychmiast. Przed wejściem
gość, kvm_vcpu_exit_request() sprawdza kvm_request_pending(),
która zwraca wartość true ze względu na nowo podniesiony KVM_REQ_HV_STIMER. Potem
vcpu_enter_guest() przerywa wpis gościa i wraca wcześniej
vcpu_run(), która wraca do vcpu_enter_guest(), restartując
cykl.

Ponieważ w tej pętli nie ma ręcznych wyników, zadanie z SCHED_FIFO
może zagłodzić wątki okresu karencji RCU, co odsłoni znalezione stragany
przez syzcaller:

rcu: INFO: rcu_preempt wykrył przestoje na procesorach/zadaniach:
rcu: (wykrywany przez 1, t=10502 migi, g=14269, q=1142 ncpus=2)
rcu: Widoczne wszystkie QS, ostatnia aktywność kthread rcu_preempt 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0
rcu: rcu_preempt kthread głodny przez 10500 migotów! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->stan=0x0 ->procesor=0
rcu: Jeśli rcu_preempt kthread nie uzyska wystarczającej ilości czasu procesora, oczekiwanym zachowaniem będzie teraz OOM.
(...)
Zadzwoń do śledzenia:
<przerwanie>
__run_hrtimer jądro/time/hrtimer.c:1773 [w linii]
__hrtimer_run_queues+0x408/0xc30 jądro/czas/hrtimer.c:1841
hrtimer_interrupt+0x45b/0xaa0 jądro/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>
<ZADANIE>
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
Kod: 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
---obcięty---

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: ffffffff8fc3d0
---truncated---

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve