CVE-2026-90293 in Linux
Сводка
по VulDB • 18.09.2026
В ядре Linux была устранена следующая уязвимость:
IB/isert: отправка буферов приема с полным функционалом после регистрации сеанса
Функция isert_put_login_tx() отправляет (post) полные буферы приема до того, как выполняется __transport_register_session(), поэтому инициатор, который не ожидает окончательного ответа Login Response, может все же выполнить команду SCSI против se_session, у которого se_tpg равен NULL — тот же сбой ядра (oops), что и в предыдущем патче, по адресу target_submit+0xbe.
Необходимо выполнять отправку из isert_get_rx_pdu(), которую предыдущий патч уже использует для отправки этого ответа, причем делать это до самой отправки: очередь приема заполняется в тот момент, когда инициатору сообщается о возможности её использования. Выделение памяти именно там сохраняет существующее свойство: сбой выделения памяти не может произойти после того, как окончательный ответ Login Response уже находится на линии (отправлен).
Очередь приема изначально пуста между окончательным запросом Login и вызовом isert_post_recvm(); данный паттс смещает второй момент позже, со среднего значения 92 мкс до 172 мкс при 1200 сеансах входа. Достичь этого окна может только тот инициатор, который отправляет данные до получения разрешения на это; в протоколах IB (InfiniBand) и RoCE его отправка будет повторяться там до появления буферов — isert_rdma_accept() запрашивает rnr_retry_count = 7. В iWARP отсутствует управление потоком RNR (Receive Not Ready), поэтому в этом случае та же самая отправка приводит к разрыву соединения.
Измерения проводились с использованием RXE, по 400 циклов входа за один прогон, с инициатором, который не ожидает: инструментированная сборка показала отсутствие вызовов isert_recv_done() до момента отправки буферов в 10 из 10 прогонов, тогда как этот инициатор приводил к сбою ядра (oops) в 8 из 10 случаев с незапатченной версией и в 5 из 10 случаев только с предыдущим патчем.
Не тестировалось: iWARP, сеансы обнаружения через iSER и реальные HCA-адаптеры.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.