CVE-2021-47229

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: aardvark: solucionó el pánico del kernel durante la transferencia de PIO. Intentar iniciar una nueva transferencia de PIO escribiendo el valor 0 en el registro PIO_START cuando la transferencia anterior aún no se ha completado (que se indica con el valor 1). en PIO_START) provoca un aborto externo en la CPU, lo que resulta en pánico del kernel: Interrupción de SError en CPU0, código 0xbf000002 - Pánico del kernel de SError - no se sincroniza: Interrupción de SError asincrónica Para evitar el pánico del kernel, es necesario rechazar una nueva transferencia de PIO cuando el anterior aún no ha terminado. Si la transferencia PIO anterior aún no ha finalizado, el kernel puede emitir una nueva solicitud PIO solo si se agotó el tiempo de espera de la transferencia PIO anterior. En el pasado, la causa root de este problema se identificó incorrectamente (como sucede a menudo durante el reentrenamiento del enlace o después de un evento de caída del enlace) y se implementó un truco especial en Trusted Firmware para detectar todos los eventos de SError en EL3, para ignorar los errores con el código 0xbf000002 y no reenviar cualquier otro error al kernel y en su lugar generar pánico desde el controlador de firmware confiable EL3. Enlaces a discusiones y parches sobre este problema: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci /20190316161243.29517-1-repk@triplefau.lt/ https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/ https://review.trustedfirmware.org/c/TF-A/trusted -firmware-a/+/1541 Pero la causa real fue el hecho de que durante el reentrenamiento del enlace o después de un evento de caída del enlace, la transferencia de PIO puede tardar más tiempo, hasta 1,44 segundos hasta que se agote el tiempo de espera. Esto aumenta la probabilidad de que el kernel emita una nueva transferencia PIO mientras que la anterior aún no ha finalizado. Después de aplicar este cambio en el kernel, es posible revertir el hack de TF-A mencionado y los eventos SError no tienen que detectarse en TF-A EL3.