CVE-2026-68100 in Linux
Сводка
по VulDB • 11.08.2026
В ядре Linux устранена следующая уязвимость:
ksmbd: проверка поля num_subauth при копировании дескриптора доступа (ACE) в set_ntacl_dacl
Функция `set_ntacl_dacl()` копирует каждый ACE из хранимого описателя безопасности, контролируемого злоумышленником, дословно в ответный DACL без проверки значения `sid.num_subauth`. Байты ACE (включая непроверенное значение `num_subauth`) поступают от аутентифицированного запроса SMB2_SET_INFO(SecInfo=DACL), который сохраняется «как есть» через функцию `ksmbd_vfs_set_sd_xattr()`; функция `parse_dacl()` отвергает некорректный ACE с помощью инструкции `break`, а не возврата ошибки, поэтому `parse_sec_desc()` всё равно возвращает успех, и malformed SD (неправильно структурированный описатель безопасности) достигает функции xattr в исходном виде.
При последующем запросе SMB2_QUERY_INFO(SecInfo=DACL) для иноды с POSIX-дескриптором доступа ACL вызовы `build_sec_desc()` -> `set_ntacl_dacl()` -> `set_posix_acl_entries_dacl()` проходят по скопированным ACE и читают
ntace->sid.sub_auth[ntace->sid.num_subauth - 1]
где значение `num_subauth` берётся напрямую из сохранённого SD. Поскольку массив `sub_auth[]` имеет фиксированный размер SID_MAX_SUB_AUTHORITIES (15), специально сформированное значение `num_subauth` (например, 255) приводит к out-of-bounds heap read (чтению за пределами буфера в динамической памяти) объёмом около 1 КБ со смещением, полностью контролируемым аутентифицированным клиентом.
Сопутствующие функции уже ограничивают это поле: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES)
Функция `set_ntacl_dacl()` является единственным несогласованным путём выполнения кода, в котором отсутствует данная проверка.
Добавлена та же самая проверка поля `num_subauth` в функции `set_ntacl_dacl()` перед копированием ACE, что соответствует ограничению, уже применяемому функцией `parse_dacl()`.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.