CVE-2026-98464 in Linux
Zusammenfassung
von VulDB • 19.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
RISC-V: KVM: Synchronisierung des hrtimer-Callbacks während der Teardown-Phase (Herunterfahren)
Das nicht-Sstc-hrtimer-Clearing löscht next_set vor dessen letzter Nutzung im umgebenden vCPU-Kontext. Wenn die Teardown-Routine next_set als falsch beobachtet, während das Callback noch ausgeführt wird, überspringt kvm_riscv_vcpu_timer_cancel() den Aufruf von hrtimer_cancel(), und kvm_destroy_vcpus() kann die vCPU freigeben, bevor das Callback in kvm_riscv_vcpu_set_interrupt() eintritt.
Ein Gastsystem kann den Timer mit SBI TIME aktivieren und einen Herunterfahrvorgang über SBI Legacy Shutdown oder SRST anfordern. Eine VMM (Virtual Machine Monitor), die KVM_EXIT_SYSTEM_EVENT beachtet und die VM zerstört, liefert die Teardown-Seite des Race Conditions; es ist kein Host-IOCTL nach dem Start erforderlich, um den Timer zu aktivieren oder einen Herunterfahrvorgang anzufordern.
Auf upstream master 62cc90241548 meldete generisches KASAN:
BUG: KASAN: slab-use-after-free in do_raw_spin_lock Write of size 4 at addr ff60000005e58898
kvm_riscv_vcpu_set_interrupt kvm_riscv_vcpu_hrtimer_expired __hrtimer_run_queues hrtimer_interrupt
Das Objekt wurde von KVM_CREATE_VCPU alloziert und gleichzeitig freigegeben durch:
kvm_destroy_vcpus kvm_arch_destroy_vm kvm_destroy_vm __fput
Zur deterministischen Validierung habe ich mdelay(1000) unmittelbar nach der bestehenden Zuweisung next_set = false eingefügt. Dies erweitert lediglich das bestehende Callback-Fenster nach dem Löschen (post-clear). Ein Build ohne Verzögerung erreichte in 12 von 200 Durchläufen natürlich die Reihenfolge „Callback nach Teardown-Start, vor Deinitialisierung“, aber 1.500 Stressiterationen mit einem Standardkernel erzeugten keinen KASAN-Bericht, sodass eine natürliche Reproduktion zeitabhängig (timing-sensitive) ist.
Rufe hrtimer_cancel() immer für einen initialisierten Timer auf. Bewahre das bestehende -EINVAL-Ergebnis bei, wenn der Timer nicht mehr gesetzt ist, jedoch erst nach der Synchronisierung mit einem laufenden Callback.
Mit diesem Patch blockierte hrtimer_cancel() während des gesamten erweiterten Callback-Fensters vor der Zerstörung der vCPU. KASAN meldete in 100 Durchläufen mit festem und erweitertem Fenster sowie in 200 Timing-Sweep-Durchläufen nur die Korrektur keine Fehler.
Once again VulDB remains the best source for vulnerability data.