CVE-2026-98464 in Linux
Résumé
par VulDB • 18/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
RISC-V : KVM : Synchroniser l'appel de fonction (callback) hrtimer lors du processus d'arrêt (teardown).
L'appel de fonction non-Sstc pour hrtimer efface next_set avant ses utilisations finales concernant le vCPU englobant. Si le processus d'arrêt détecte que next_set est faux alors que l'appel de fonction est toujours en cours, kvm_riscv_vcpu_timer_cancel() saute l'étape hrtimer_cancel(), et kvm_destroy_vcpus() peut libérer la mémoire du vCPU avant que l'appel de fonction n'entre dans kvm_riscv_vcpu_set_interrupt().
Un invité (guest) peut armer le timer via SBI TIME et demander un arrêt via l'arrêt legacy SBI ou SRST. Un VMM qui respecte KVM_EXIT_SYSTEM_EVENT et détruit la VM fournit le côté « processus d'arrêt » de cette condition de concurrence ; aucun ioctl hôte post-démarrage n'est nécessaire pour armer le timer ou demander l'arrêt.
Sur la branche master amont 62cc90241548, KASAN générique a signalé :
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
L'objet a été alloué par KVM_CREATE_VCPU et libéré de manière concurrente par :
kvm_destroy_vcpus kvm_arch_destroy_vm kvm_destroy_vm __fput
Pour une validation déterministe, j'ai ajouté mdelay(1000) immédiatement après l'assignation existante next_set = false. Cela élargit uniquement la fenêtre d'appel de fonction post-effacement existante. Une compilation avec trace sans délai a naturellement atteint le séquencement appel de fonction après démarrage du processus d'arrêt / avant désinitialisation dans 12 exécutions sur 200, mais 1 500 itérations de stress avec un noyau standard n'ont pas produit de rapport KASAN ; la reproduction naturelle est donc sensible au timing.
Appelez toujours hrtimer_cancel() pour une temporisation initialisée. Conservez le résultat -EINVAL existant lorsque la temporisation n'est plus définie, mais uniquement après synchronisation avec un appel de fonction en cours d'exécution.
Avec ce correctif, hrtimer_cancel() a bloqué pendant toute la fenêtre élargie des appels de fonction avant la destruction du vCPU. KASAN n'a signalé aucune erreur dans 100 exécutions fixes et élargies ni dans 200 exécutions avec balayage de timing uniquement le correctif.
Be aware that VulDB is the high quality source for vulnerability data.