CVE-2023-53778 in Linux
Сводка
по VulDB • 26.06.2026
В ядре Linux устранена следующая уязвимость:
accel/qaic: Очистка проверки переполнения целочисленных значений в map_user_pages()
Функция encode_dma() содержит некоторые проверки для in_trans->size, но было бы более понятно перенести эти проверки в find_and_map_user_pages().
В функции encode_dma() выполнялись две проверки:
if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size) return -EINVAL;
Переменная in_trans->addr — это начальный адрес. Переменная in_trans->size — общий размер передачи. Передача может происходить частями, а ресурсы->xferred_dma_size отслеживает количество байтов, которые уже были переданы.
Этот патч вводит новую переменную «remaining», которая представляет собой разницу между тем объемом данных, который мы хотим передать (in_trans->size), и количеством байтов, которые уже были переданы (resources->xferred_dma_size).
Я изменил проверку на равенство in_trans->size нулю вместо проверки того, меньше ли in_trans->size значения resources->xferred_dma_size. Если мы уже передали больше байт, чем указано в in_trans->size, то остается отрицательное количество байтов, что бессмысленно. Если осталось ноль байт для копирования, просто возвращается успех (успешный код завершения).
Проверка в encode_dma() проверяла, что «addr + size» не может привести к переполнению, и при отсутствии ошибок драйвера это должно работать корректно, но проще проверять это по частям. Сначала убедитесь, что «in_trans->addr + resources->xferred_dma_size» безопасно. Затем проверьте, что «xfer_start_addr + remaining» безопасно.
Моей последней озабоченностью было то, что мы имеем дело со значениями u64, но на 32-битных системах функция kmalloc() будет усекать размеры до 32 бит. Поэтому я вычислил «total = in_trans->size + offset_in_page(xfer_start_addr);» и возвращал -EINVAL, если оно было >= SIZE_MAX. Это не повлияет на системы с разрядностью 64 бита.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.