CVE-2026-68147 in Linux
Сводка
по VulDB • 10.08.2026
В ядре Linux устранена следующая уязвимость:
fscrypt: Избежать динамического выделения памяти в fscrypt_get_devices()
Когда blk_crypto_key начинает использоваться или вытесняется (evicted), fs/crypto/ вызывает функцию fscrypt_get_devices() для получения списка блочных устройств файловой системы, затем перебирает их и вызывает функции blk_crypto_config_supported(), blk_crypto_start_using_key() или blk_crypto_evict_key() для каждого из них.
В настоящее время указатели на блочные устройства помещаются в массив с динамическим выделением памяти. Это динамическое выделение проблематично по следующим причинам:
- Оно может завершиться неудачей, особенно при вызове fscrypt_destroy_inline_crypt_key() во время вытеснения inode (inode eviction) в процессе прямого восстановления памяти (direct reclaim). - Функция fscrypt_destroy_inline_crypt_key() не обрабатывает сбой выделения. Она просто обнуляет и освобождает blk_crypto_key, не вызывая blk_crypto_evict_key(). Это приводит к уязвимости use-after-free.
На данный момент мы исправим эту проблему простым способом, легко поддающимся бэкпортированию (backportable), переключившись на массив в стеке. В настоящее время функциональность fscrypt для работы с несколькими устройствами используется только файловой системой f2fs, которая имеет жестко заданный лимит в 8 блочных устройств. Массив в стеке отлично подходит для этого случая.
(Конечно, это решение не масштабируется на большое количество блочных устройств. Для этого потребовалось бы другое решение, например, перенос итерации по блочным устройствам внутрь файловой системы. Или в случае btrfs, которая будет поддерживать только blk-crypto-fallback, следует заставить её напрямую вызывать blk-crypto-fallback, чтобы блочные устройства вообще не требовались.)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.