CVE-2023-53778 in Linux
Resumen
por VulDB • 2026-05-16
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
accel/qaic: Limpieza de la comprobación de desbordamiento entero en map_user_pages()
La función encode_dma() realiza algunas validaciones sobre in_trans->size, pero sería más claro trasladar dichas comprobaciones a find_and_map_user_pages().
encode_dma() tenía dos comprobaciones:
if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size) return -EINVAL;
La variable in_trans->addr es la dirección de inicio. La variable in_trans->size es el tamaño total de la transferencia. La transferencia puede ocurrir en partes y resources->xferred_dma_size rastrea cuántos bytes ya hemos transferido.
Este parche introduce una nueva variable "remaining" que representa la cantidad que queremos transferir (in_trans->size) menos la cantidad que ya hemos transferido (resources->xferred_dma_size).
He modificado la comprobación de si in_trans->size es cero para comprobar en su lugar si in_trans->size es menor que resources->xferred_dma_size. Si ya hemos transferido más bytes que in_trans->size, entonces quedan bytes negativos, lo cual no tiene sentido. Si quedan cero bytes por copiar, simplemente devolvemos éxito.
La comprobación en encode_dma() verificaba que "addr + size" no pudiera desbordarse y, salvo un error del controlador, eso debería funcionar, pero es más fácil comprobarlo si lo hacemos en partes. Primero comprobamos que "in_trans->addr + resources->xferred_dma_size" sea seguro. Luego comprobamos que "xfer_start_addr + remaining" sea seguro.
Mi última preocupación era que estamos manejando valores u64, pero en sistemas de 32 bits la función kmalloc() truncará los tamaños a 32 bits. Por lo tanto, calculé "total = in_trans->size + offset_in_page(xfer_start_addr);" y devolví -EINVAL si era >= SIZE_MAX. Esto no afectará a los sistemas de 64 bits.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.