Descripción
En el kernel de Linux se resolvió la siguiente vulnerabilidad: RISC-V: KVM: Synchronize hrtimer callback during teardown El callback de hrtimer sin Sstc limpia next_set antes de sus últimos usos de la vCPU que lo contiene. Si durante el desmontaje se observa next_set como falso mientras el callback aún se ejecuta, kvm_riscv_vcpu_timer_cancel() omite hrtimer_cancel() y kvm_destroy_vcpus() puede liberar la vCPU antes de que el callback entre en kvm_riscv_vcpu_set_interrupt(). Un invitado puede armar el temporizador con SBI TIME y solicitar el apagado con SBI legacy shutdown o SRST. Un VMM que atienda KVM_EXIT_SYSTEM_EVENT y destruya la VM aporta el lado de desmontaje de la condición de carrera; no se necesita ningún ioctl del host posterior al lanzamiento para armar o solicitar el desmontaje. En upstream master 62cc90241548, KASAN genérico reportó: 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 El objeto fue asignado por KVM_CREATE_VCPU y liberado de forma concurrente por: kvm_destroy_vcpus kvm_arch_destroy_vm kvm_destroy_vm __fput Para una validación determinista, se agregó mdelay(1000) inmediatamente después de la asignación existente next_set = false. Esto solo amplía la ventana existente del callback posterior a la limpieza. Una compilación de trazas sin retardo alcanzó de forma natural el orden callback-después-del-inicio-del-desmontaje/antes-de-deinit en 12 de 200 ejecuciones, pero 1.500 iteraciones de estrés con el kernel estándar no produjeron un reporte de KASAN, por lo que la reproducción natural depende de la sincronización. La corrección invoca siempre hrtimer_cancel() para un temporizador inicializado. Se conserva el resultado -EINVAL existente cuando el temporizador ya no está establecido, pero solo después de sincronizar con un callback en ejecución. Con este parche, hrtimer_cancel() se bloqueó durante toda la ventana ampliada del callback antes de la destrucción de la vCPU. KASAN no reportó errores en 100 ejecuciones con la corrección y la ventana ampliada, ni en 200 ejecuciones de barrido de sincronización solo con la corrección.
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- Linux Afectadas: 3a9f66cb25e18a3eeca36c08d9f823a35b3ddc22 y anteriores a 9bdbae64ae0dab93041ebc57ec4e93def793fc2d · 3a9f66cb25e18a3eeca36c08d9f823a35b3ddc22 y anteriores a 2af03b606aadaaeb386658ef798c79bdcdef87c1 · 3a9f66cb25e18a3eeca36c08d9f823a35b3ddc22 y anteriores a e66aced74f0122380603c9910a71d77618b28f0e · 3a9f66cb25e18a3eeca36c08d9f823a35b3ddc22 y anteriores a ea91f05a55b807ead3166546a2c75f4185ca645f · 3a9f66cb25e18a3eeca36c08d9f823a35b3ddc22 y anteriores a 3cc6184bd5920c9685d87f4e260568feba08650d · 3a9f66cb25e18a3eeca36c08d9f823a35b3ddc22 y anteriores a aaad136d56d91252517272b68cd533e5714698d5
- Linux Afectadas: 5.16 No afectadas: 6.1.189 · 6.6.158 · 6.12.112 · 6.18.55 · 7.2.9 · 7.3
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en git.kernel.orggit.kernel.org/stable/c/9bdbae64ae0dab93041ebc57ec4e93def793fc2d
- Referencia en git.kernel.orggit.kernel.org/stable/c/2af03b606aadaaeb386658ef798c79bdcdef87c1
- Referencia en git.kernel.orggit.kernel.org/stable/c/e66aced74f0122380603c9910a71d77618b28f0e
- Referencia en git.kernel.orggit.kernel.org/stable/c/ea91f05a55b807ead3166546a2c75f4185ca645f
- Referencia en git.kernel.orggit.kernel.org/stable/c/3cc6184bd5920c9685d87f4e260568feba08650d
- Referencia en git.kernel.orggit.kernel.org/stable/c/aaad136d56d91252517272b68cd533e5714698d5
Ver el texto original en inglés (CVE.org)
RISC-V: KVM: Synchronize hrtimer callback during teardown
In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Synchronize hrtimer callback during teardown The non-Sstc hrtimer callback clears next_set before its final uses of the enclosing vCPU. If teardown observes next_set as false while the callback is still running, kvm_riscv_vcpu_timer_cancel() skips hrtimer_cancel() and kvm_destroy_vcpus() can free the vCPU before the callback enters kvm_riscv_vcpu_set_interrupt(). A guest can arm the timer with SBI TIME and request shutdown with SBI legacy shutdown or SRST. A VMM that honors KVM_EXIT_SYSTEM_EVENT and destroys the VM supplies the teardown side of the race; no post-launch host ioctl is needed to arm or request teardown. On upstream master 62cc90241548, generic KASAN reported: 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 The object was allocated by KVM_CREATE_VCPU and freed concurrently by: kvm_destroy_vcpus kvm_arch_destroy_vm kvm_destroy_vm __fput For deterministic validation, I added mdelay(1000) immediately after the existing next_set = false assignment. This only widens the existing post-clear callback window. A no-delay trace build naturally reached the callback-after-teardown-start/before-deinit ordering in 12 of 200 runs, but 1,500 stock-kernel stress iterations did not produce a KASAN report, so natural reproduction is timing-sensitive. Always invoke hrtimer_cancel() for an initialized timer. Preserve the existing -EINVAL result when the timer is no longer set, but only after synchronizing with a running callback. With this patch, hrtimer_cancel() blocked for the full widened callback window before vCPU destruction. KASAN reported no error in 100 fixed-and-widened runs or 200 fix-only timing-sweep runs.