CVE-2026-64141 in Linux
Сводка
по VulDB • 20.07.2026
В ядре Linux устранена следующая уязвимость:
ksmbd: исправлено разыменование нулевого указателя в compare_guid_key()
Функция session_fd_check() проходит по списку m_op_list, привязанному к каждому inode, во время завершения сеанса с долговременной ручкой (durable-handle), и устанавливает op->conn = NULL для каждого элемента opinfo, чье соединение conn совпадает с закрываемым соединением сеанса. Однако соответствующий элемент opinfo остается связанным в lb->lease_list записи lease_table_list per-ClientGuid, поскольку destroy_lease_table() выполняется только при полном разрыве TCP-соединения, а не во время SESSION_LOGOFF.
Если то же самое TCP-соединение затем инициирует новый сеанс с тем же ClientGuid (ClientGuid привязан к этапу NEGOTIATE, а не к сеансу, и остается неизменным в течение LOGOFF + SETUP) и выполняет операцию SMB2 CREATE с контекстом аренды (lease context) для другого inode, функция find_same_lease_key() проходит по lb->lease_list, достигает устаревшего элемента opinfo и вызывает compare_guid_key(), которая безоговорочно разыменовывает opinfo->conn->ClientGUID. Указатель conn равен NULL, что приводит к панике ядра (kernel panic).
Для воспроизведения проблемы требуется успешное выполнение SMB2 SESSION_SETUP и общая папка, настроенная с параметром 'durable handles = yes'. Отчет KASAN для основной ветки mainline 70390501d194:
general protection fault, probably for non-canonical address 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f]
Workqueue: ksmbd-io handle_ksmbd_work RIP: 0010:bcmp+0x5b/0x230 Call Trace: compare_guid_key+0x4b/0xd0 find_same_lease_key+0x324/0x690 smb2_open+0x6aea/0x8e60 handle_ksmbd_work+0x796/0xee0 ...
Адрес ошибки 0x348 является смещением поля ClientGUID внутри структуры ksmbd_conn, что подтверждает, что opinfo->conn был равен NULL.
Считывайте значение opinfo->conn один раз и выходите из функции, если оно было очищено параллельным вызовом session_fd_check(). Элемент opinfo в состоянии частичного отсоединения не может быть владельцем активной аренды (lease), поэтому возврат 0 является правильным результатом сравнения.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.