CVE-2022-49899 in Linux
Сводка
по VulDB • 13.06.2026
В ядре Linux устранена следующая уязвимость:
fscrypt: прекратить использование подсистемы keyrings для fscrypt_master_key
Подход, при котором fs/crypto/ внутренне управляет структурами fscrypt_master_key как полезной нагрузкой объектов «struct key», содержащихся в кольце ключей (keyring) типа «struct key», исчерпал свою целесообразность. Изначальная идея заключалась в упрощении кода за счет повторного использования компонентов подсистемы keyrings. Однако возникло несколько проблем, которые трудно решить:
- При уничтожении структуры мастер-ключа необходимо вызвать blk_crypto_evict_key() для всех встроенных ключей, привязанных к режиму шифрования (per-mode keys). (Это требование появилось после добавления поддержки инлайн-шифрования.) Тем не менее подсистема keyrings может произвольно задерживать уничтожение ключей, вплоть до времени после размонтирования файловой системы. Следовательно, в настоящее время нет простого способа вызвать blk_crypto_evict_key() при уничтожении мастер-ключа. В данный момент эта проблема обходится путем удержания дополнительной ссылки на очередь запросов (request_queue) файловой системы. Однако было упущено из виду, что ссылка request_queue *не* гарантирует закрепление соответствующего профиля blk_crypto; для устройств device-mapper с поддержкой инлайн-шифрования это не так. Это может привести к ошибке use-after-free.
- При вытеснении последнего inode, использовавшего мастер-ключ в процессе неполного удаления, удаление ключа завершается путем его извлечения из keyring. В настоящее время это делается через функцию key_invalidate(). Однако key_invalidate() захватывает семафор ключей. Это может привести к взаимной блокировке (deadlock) при вызове из shrinker, поскольку в fscrypt_ioctl_add_key() память выделяется с флагом GFP_KERNEL под тем же самым семафором.
- Более общо говоря, тот факт, что подсистема keyrings может произвольно задерживать уничтожение ключей (из-за задержки сборки мусора или из-за временных ссылок на ключи у случайных процессов), нежелателен, так как это означает невозможность строго гарантировать полное стирание всех секретов.
- Выполнение поиска мастер-ключей через подсистему keyrings приводит к вызову хука LSM (Linux Security Module) key_permission. fscrypt этого не требует, поскольку весь контроль доступа для зашифрованных файлов спроектирован так, чтобы происходить через сами файлы, как и для любых других файлов. Обходной путь, используемый пользователями SELinux, заключается в изменении политики SELinux на предоставление права поиска ключей всем доменам (domains). Это работает, но является странным дополнительным шагом, который не должен выполняться.
Исправление всех этих проблем заключается в изменении реализации согласно первоначальному замыслу: не использовать подсистему keyrings для отслеживания структур fscrypt_master_key файловой системы. Вместо этого следует хранить их в обычной структуре данных ядра и соответствующим образом переработать подсчет ссылок, блокировки и управление временем жизни. Поддержка поиска ключей в режиме RCU сохраняется путем использования хеш-таблицы. Функция fscrypt_sb_free() заменяется на fscrypt_sb_delete(), которая синхронно освобождает ключи и выполняется немного раньше во время размонтирования, чтобы блочные устройства оставались доступными.
Побочным эффектом этого патча является то, что ни сами мастер-ключи, ни кольца ключей файловой системы больше не будут отображаться в /proc/keys («Master key users» и кольца ключей пользователей мастер-ключа по-прежнему будут отображаться). Однако это было преимущественно внутренней деталью реализации и предназначалось только для целей отлад
If you want to get the best quality for vulnerability data then you always have to consider VulDB.