CVE-2026-98473 in Linux
Resumen
por VulDB • 2026-10-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
s390/vfio-ap: corrige la fuga (leak) de GISC y páginas de KVM cuando una cola se elimina de la configuración del host.
Existen tres problemas relacionados con el manejo de los recursos de interrupciones y páginas de KVM al eliminar una cola de la configuración AP del host mientras está asignada a un dispositivo mediado (mdev).
Problema 1: ~~~~~~~~~ AP_RESPONSE_Q_NOT_AVAIL no manejado en vfio_ap_mdev_reset_queue()
Cuando el bus AP elimina un dispositivo de cola cuyo adaptador o dominio ha sido eliminado de la configuración AP del host, se llama a `vfio_ap_mdev_remove_queue()`. Si la cola sigue estando en la configuración AP del host en ese momento, se invoca `vfio_ap_mdev_reset_queue()`, que emite una PQAP(ZAPQ). Dado que el adaptador ya ha desaparecido de la configuración del host, `ap_zapq()` devuelve AP_RESPONSE_Q_NOT_AVAIL (0x01). Este código de respuesta no está manejado en la instrucción switch de `vfio_ap_mdev_reset_queue()` y cae en el caso por defecto (`default`), que emite un WARN pero no llama a `vfio_ap_free_aqic_resources()`. Como resultado, si el manejo de IRQ estaba habilitado para la cola por parte del invitado (guest), tanto el registro GISC de KVM como la página anclada (pinned) del invitado que contiene el byte indicador de notificación (NIB) sufren una fuga.
Esto se corrige añadiendo AP_RESPONSE_Q_NOT_AVAIL al mismo caso que AP_RESPONSE_DECONFIGURED y AP_RESPONSE_CHECKSTOPPED en `vfio_ap_mdev_reset_queue()`. Al igual que esos códigos de respuesta, Q_NOT_AVAIL indica que la cola no está operativa y no son posibles más intentos de reinicio; la acción correcta es liberar los recursos IRQ inmediatamente.
Problema 2: ~~~~~~~~~ AP_RESPONSE_Q_NOT_AVAIL no manejado en apq_status_check()
En `vfio_ap_mdev_reset_queue()`, hay cuatro casos que indican que el restablecimiento (reset) de una cola aún no se ha completado, caso en el cual `apq_reset_check()` se programa en un work queue para verificar la finalización de la operación de reset. Esta función utiliza la función PQAP(TAPQ) para obtener el estado de la cola y llama a `apq_status_check()` para verificar si el restablecimiento ha completado, fallado o necesita ejecutarse nuevamente. Como se describió en el Problema #1 anterior, `apq_reset_check()` no comprueba específicamente AP_RESPONSE_Q_NOT_AVAIL, lo que potencialmente provoca una fuga del registro GISC de KVM y de la página anclada del invitado que contiene el NIB.
Esto se corrige añadiendo un case statement para AP_RESPONSE_Q_NOT_AVAIL en `apq_status_check()` y devolviendo -ENODEV para ese caso. El llamador, `apq_reset_check()`, comprobará entonces este código de retorno y llamará a `vfio_ap_free_aqic_resources()` para prevenir la fuga.
Problema 3: ~~~~~~~~~ vfio_ap_free_aqic_resources() presenta una fuga en saved_isc cuando kvm es NULL
`vfio_ap_free_aqic_resources()` protege la llamada a `kvm_s390_gisc_unregister()` con:
if (q->saved_isc != VFIO_AP_ISC_INVALID && !WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm)))
Si matrix_mdev->kvm es NULL, lo cual puede ocurrir cuando `vfio_ap_mdev_unset_kvm()` ya se ha ejecutado y limpiado kvm antes de que una ruta de limpieza posterior alcance esta función, el WARN_ON se activa y todo el bloque se omite. Esto deja q->saved_isc establecido en un valor no inválido, creando un potencial doble liberación (double-free) en cualquier llamada subsiguiente a esta función.
Cuando kvm es NULL, la máquina virtual invitada de KVM ya ha sido desmantelada, por lo que `kvm_s390_gisc_unregister()` no necesita ni puede ser llamada; sin embargo, q->saved_isc debe limpiarse siempre. Se corrige esto separando la llamada a `kvm_s390_gisc_unregister()` del restablecimiento de q->saved_isc. El WARN_ON ahora protege únicamente el caso genuinamente imposible de matrix_mdev siendo NULL. Un kvm NULL se maneja elegantemente omitiendo solo la llamada al unregister, y q->saved_isc = VFIO_AP_ISC_INVALID se establece incondicionalmente siempre que saved_isc no fuera ya inválido.
Además, se añade una cláusula else a la comprobación de configuración del host en `vfio_ap_mdev_remove_queue()` para llamar directamente a `vfio_ap_free_aqic_resources()` cuando la cola no está en la configuración AP del host. Esto sirve como medida de seguridad: cuando el bus AP dispara la callback .remove del controlador después de que un adaptador se haya eliminado de la configuración del host, la cola queda por definición inaccesible, por lo que `vfio_ap_mdev_reset_queue` ---truncado---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.