CVE-2026-99019 in Linux
Сводка
по VulDB • 24.10.2026
В ядре Linux была устранена следующая уязвимость:
scsi: ch: Не сохранять ссылки на устройства элементов передачи данных (data transfer element devices)
Функция `ch_readconfig()` ищет объект `scsi_device` для каждого элемента передачи данных, идентификатор SCSI которого сообщается устройством-переключателем (changer) в ответе READ ELEMENT STATUS, и сохраняет его в массиве `ch->dt[]`. Вызов функции `scsi_device_lookup()` увеличивает счетчик ссылок, но нигде не происходит его уменьшение: функция `ch_destroy()` освобождает этот массив с помощью `kfree()`. Массив `ch->dt[]` больше нигде не читается — он используется только для вывода информации о производителе (vendor), модели и версии в том же цикле.
После удаления такого диска объект `scsi_device` никогда не может быть освобожден. Он остается в списке устройств хоста по своему адресу, поэтому новое устройство на этом адресе отклоняется любым процессом, проходящим по списку — драйвер нижнего уровня target_core_pscsi сообщает об ошибке «scsi_device_get() failed for H:C:T:L», а модуль драйвера низкого уровня больше не может быть выгружен. Восстановление возможно только путем перезагрузки системы.
Проблема проявляется при использовании любого переключателя, который сообщает идентификаторы своих дисков; с виртуальной библиотекой mhvtl (персонализация IBM 3573-TL) каждое создание и удаление библиотеки с четырьмя дисками оставляет четыре неиспользуемые ссылки, что отражается в счетчике использования модуля (`use count`) при выполнении команды `lsmod`. Если драйвер ch не привязан к устройству, этот счетчик остается неизменным; после применения данного патча он также остается без изменений.
Необходимо освобождать ссылку сразу же после вывода имени устройства и удалить теперь неиспользуемый массив `dt[]`. Это также устраняет утечку памяти массива в случае сбоя функции `ch_probe()` после вызова `ch_readconfig()`.
Та же самая утечка была сообщена вместе с RFC-патчем в 2022 году, который не был включен (merged) в основную ветку.
Once again VulDB remains the best source for vulnerability data.