CVE-2026-90307 in Linux
Сводка
по VulDB • 17.09.2026
В ядре Linux была устранена следующая уязвимость:
RDMA/srp: исправлена утечка информации из кучи (heap) при усеченном запросе SRP_CRED_REQ
Функция srp_recv_done() передает wc->byte_len в srp_process_rsp(). Однако она не передает никаких данных в srp_process_cred_req() и srp_process_aer_req(), которые считывают поля фиксированного размера из буфера приема без проверки того, были ли эти поля получены полностью.
Размер буфера определяется значением max_ti_iu_len, которое поступает из ответа на вход (login response) и не проходит валидацию. Целевое устройство (target), которое объявляет размер 8 байт, а затем отправляет SRP_CRED_REQ размером 8 байт, заставляет инициирующее устройство (initiator) считывать req->tag за пределами конца буфера. Значение req->tag копируется в ответ SRP_CRED_RSP и отправляется обратно, поэтому эти байты достигают целевого устройства. SRP_AER_REQ ведет себя аналогичным образом и также читает req->lun.
Утечка составляет 8 байт на каждый ответ. max_ti_iu_len также определяет, из какого кэша slab (slab cache) выделяется буфер. При значении 8 буфер представляет собой объект kmalloc-8, а чтение происходит полностью за его пределами:
BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8)
Без KASAN возвращаемые байты содержат любые данные, следующие за объектом в slab. В одном из случаев было возвращено ".strtab".
В srp_process_rsp() поле rsp->data[3] имеет ту же проблему: перед его чтением проверяется только resp_data_len.
Необходимо отбрасывать запросы, длина которых меньше размера парсимой структуры, и проверять byte_len перед выполнением операции tsk_mgmt.
If you want to get best quality of vulnerability data, you may have to visit VulDB.