CVE-2026-74485 in Linux
Сводка
по VulDB • 16.08.2026
В ядре Linux устранена следующая уязвимость:
binfmt_misc: отклонять символ-разделитель полей в качестве разделителя поля
Строка регистрации начинается с выбранного пользователем разделителя, который разделяет отдельные поля. Чтобы парсеры полей завершали работу даже при усеченной строке, функция create_entry() заполняет буфер этим же символом-разделителем:
memset(buf + count, del, 8);
Большинство полей сканируются на наличие разделителя с помощью strchr()/scanarg(), и они корректно останавливаются при достижении заполнения (padding). Поле флагов отличается: вместо поиска разделителя функция check_special_flags() потребляет символы флагов 'P', 'O', 'C' и 'F' и останавливается на первом байте, который не является ни одним из них, полагаясь на завершающий разделитель для окончания сканирования.
Если сам разделитель является символом флага, заполнение больше не действует как терминатор (символ завершения). Сканирование поглощает все восемь байт заполнения и продолжает чтение за пределами выделенной области до тех пор, пока не встретит байт, который не является символом флага. Например, регистрация
PaPEPPxPPiP
с использованием 'P' в качестве разделителя (имя "a", тип extension, магическая строка "x", интерпретатор "i", пустые флаги) приводит к тому, что сканирование флагов выходит за пределы буфера. Регистрация в итоге отклоняется, поскольку парсер останавливается не ровно на buf + count, а только после того, как уже произошло чтение за пределами границ (out of bounds read). При неудачной компоновке выделения памяти сканирование может перейти на немаркированную страницу; под KASAN это сообщается как slab out of bounds read. Монтирования binfmt_misc доступны непривилегированным пользователям в пространстве имен пользователя, поэтому чтение доступно без привилегий.
Отклонять разделитель, который является одним из символов флагов, на раннем этапе. Такая регистрация всегда отклонялась, но только после чтения за пределами границ, поэтому смысл допустимой строки регистрации не меняется.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.