Vulnerabilidad en kernel de Linux (CVE-2022-48853)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: swiotlb: corrige la fuga de información con DMA_FROM_DEVICE El problema que estoy abordando fue descubierto mediante la prueba LTP que cubre cve-2018-1000204. A continuación se ofrece una breve descripción de lo que sucede: 1) El caso de prueba emite un código de comando 00 (UNIDAD DE PRUEBA LISTO) a través de la interfaz SG_IO con: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV y un dxferp correspondiente. Lo peculiar de esto es que TUR no lee desde el dispositivo. 2) En sg_start_req() la invocación de blk_rq_map_user() efectivamente rebota el buffer del espacio de usuario. Como si el dispositivo fuera a transferirse a él. Desde El commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") nos aseguramos de que este primer búfer de rebote esté asignado con GFP_ZERO. 3) Durante el resto de la historia seguimos ignorando que tenemos un TUR, por lo que el dispositivo no tocará el buffer que preparamos como si tuviéramos una situación del tipo DMA_FROM_DEVICE. Mi configuración utiliza un dispositivo virtio-scsi y el búfer asignado por SG se asigna mediante la función virtqueue_add_split() que usa DMA_FROM_DEVICE para los sgs "in" (aquí scatter-gather y no genéricos scsi). Este mapeo implica rebotar a través de swiotlb (necesitamos swiotlb para hacer virtio en un invitado protegido como s390 Secure Execution o AMD SEV). 4) Cuando finaliza el SCSI TUR, primero copiamos el contenido del segundo búfer de rebote (es decir, swiotlb) (que probablemente contiene algunos datos de IO anteriores) al primer búfer de rebote, que contiene todos ceros. Luego volvemos a copiar el contenido del primer búfer de rebote al búfer de espacio de usuario. 5) El caso de prueba detecta que el búfer, que inicializó en cero, no es todo ceros y falla. Se puede argumentar que se trata de un problema de swiotlb, porque sin swiotlb se filtran todos los ceros, y swiotlb debería ser transparente en el sentido de que no afecte el resultado (si todos los demás participantes se portan bien). Copiar el contenido del búfer original en el búfer swiotlb es la única forma que se me ocurre para hacer que swiotlb sea transparente en tales escenarios. Entonces, hagamos eso en caso de duda, pero permitamos que el controlador nos diga que se sobrescribirá todo el búfer asignado, en cuyo caso podemos preservar el comportamiento anterior y evitar el impacto en el rendimiento del rebote adicional.