CVE-2026-80734 в Linux Kernel: дефект btrfs, уязвимые версии и защита

CVE: CVE-2026-80734
Продукт: Linux Kernel
Дата публикации: 03.09.2026
Критичность: HIGH
CVSS: 8.8 (3.1)
EPSS: 0,20%; процентиль 9,56%
CISA KEV: нет подтверждения в каталоге CISA KEV

Краткое описание​

В подсистеме btrfs ядра Linux выявлена ошибка инициализации метаданных inode, приводящая к срабатыванию ASSERT() и падению ядра. Дефект проявляется при работе с томами, смонтированными с размером блока 8 КБ, и устраняется перемещением вызовов настройки флагов mapping в ветку кода, обрабатывающую кэшированные inode. Материал описывает механику сбоя, условия воспроизведения и порядок проверки актуальности ядра.

Основные характеристики​

Риск заключается в отказе в обслуживании: при определённых условиях кэширования inode ядро завершает работу аварийно. Ошибка затрагивает логику инициализации метаданных btrfs и не связана с удалённым выполнением кода.

• CVSS 3.1: 8.8 (HIGH), вектор CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Оценка отражает потенциальное влияние на конфиденциальность, целостность и доступность при локальном доступе с правами.
  
• EPSS: 0,20% (сырое значение 0.00198, процентиль 9,56%). Показатель указывает на низкую вероятность эксплуатации в ближайший год.
  
• Тип атаки: Отказ в обслуживании (DoS) через срабатывание ASSERT() в extent_io.c.
  
• CWE: Идентификатор не присвоен в доступных источниках.
  
• Статус: CVE зафиксирован, исправление включено в ветки stable Linux kernel.
  

Какие продукты и версии затронуты​

Уязвимость затрагивает подсистему btrfs в ядре Linux. Точный перечень версий, в которых присутствует дефект, не раскрыт в предоставленных источниках, однако известно, что исправление было внесено в ветки stable.

• Подсистема: btrfs (файловая система).
  
• Условие: Использование томов btrfs с размером блока 8 КБ (8192 байта).
  
• Статус: Исправление включено в актуальные ветки stable Linux kernel.
  

Для определения актуальности конкретной системы необходимо сверить версию ядра с официальными релизами и наличием патча 0d26249671171ab759cb4fdce673554a690fa655.

Причина уязвимости​

Причина дефекта кроется в логике инициализации inode при повторном чтении из кэша. Функция btrfs_read_locked_inode() содержит ветвление, которое пропускает вызовы btrfs_update_inode_mapping_flags() и btrfs_set_inode_mapping_order(), если inode уже был заполнен ранее (условие filled == true).

В результате для кэшированных inode минимальный порядок folio (minimal folio order) остаётся равным 0, хотя для блоков 8 КБ он должен быть 1. Это приводит к тому, что при последующих операциях с page cache система пытается работать с folio меньшего размера, чем блок файловой системы, что нарушает инварианты выравнивания и вызывает срабатывание ASSERT() в extent_io.c.

Как работает атака​

Атака эксплуатирует ошибку в обработке метаданных btrfs. Злоумышленник с локальными правами создаёт условия, при которых inode попадает в кэш, затем выгружается из памяти (например, через drop_caches или давление на память) и снова читается.

При повторном чтении функция btrfs_iget() находит существующий delayed_node в xarray root->delayed_nodes. Код использует этот узел для инициализации нового inode, но из-за логической ошибки пропускает установку корректных флагов mapping. В итоге система получает folio с неправильным размером, что приводит к срабатыванию проверки IS_ALIGNED и аварийному завершению работы ядра (kernel panic).

Условия успешной эксплуатации​

Для успешного срабатывания уязвимости необходимо выполнение ряда условий:

• Файловая система: Система должна использовать btrfs.
  
• Размер блока: Том btrfs должен быть смонтирован с размером блока 8 КБ (8192 байта).
  
• Размер страницы: Размер страницы ОС должен быть 4 КБ (стандартная конфигурация x86_64).
  
• Доступ: Требуется локальный доступ к системе с правами на создание файлов и манипуляцию кэшем.
  
• Состояние кэша: Необходимо, чтобы inode был выгружен из памяти и затем снова прочитан.
  

Возможный сценарий атаки​

Сценарий атаки имитирует поведение, зафиксированное в тесте generic/795. Злоумышленник выполняет операции с файлами на томе btrfs (8 КБ), что приводит к созданию inode и его кэшированию. Далее он инициирует выгрузку кэша (например, через запись в /proc/sys/vm/drop_caches или естественное давление на память).

После выгрузки inode из памяти злоумышленник инициирует повторное чтение данных этого файла (например, через copy_file_range или прямое чтение). При этом btrfs_iget() находит сохранённый delayed_node, но пропускает инициализацию флагов mapping. При последующей операции записи или чтения page cache система сталкивается с несоответствием размера folio и блока, что вызывает срабатывание ASSERT() и падение ядра.

Есть ли публичный эксплойт​

Публичный эксплойт в виде готового PoC или кода для удалённой атаки в предоставленных источниках не указан. Однако в описании CVE приведён детальный сценарий воспроизведения (тест generic/795), который подтверждает возможность вызова падения ядра. Это является техническим описанием уязвимости, а не подтверждённой эксплуатацией в реальных атаках.

Отсутствие сведений о публичном эксплойте не означает, что он не существует. Разработчики ядра предоставили полный стек вызовов и условия, достаточные для создания PoC.

Признаки эксплуатации​

Специфичные индикаторы компрометации (IOC) для этой уязвимости в источниках не описаны. Однако можно использовать общие, неспецифичные признаки аномальной работы файловой системы:

• Падение ядра: Записи в dmesg или системном журнале о kernel BUG, Oops или panic с упоминанием btrfs и extent_io.c.
  
• Аномальные операции: Частые вызовы drop_caches или необычная активность процессов, работающих с файлами на томах btrfs.
  
• Ошибки I/O: Сообщения о сбоях при чтении/записи файлов на btrfs-томах с блоками 8 КБ.
  

Эти признаки не являются уникальными для CVE-2026-80734 и могут указывать на другие проблемы.

Как обнаружить атаку​

Для обнаружения попыток эксплуатации или срабатывания уязвимости рекомендуется мониторинг системных журналов:

• dmesg: Поиск записей, содержащих assert_folio_range, btrfs_read_folio или kernel BUG at extent_io.c.
  
• Системный журнал: Анализ логов journalctl на наличие сообщений о падении ядра или ошибках в подсистеме btrfs.
  
• Мониторинг процессов: Отслеживание аномальной активности процессов, выполняющих операции с файлами на btrfs-томах, особенно в сочетании с операциями по выгрузке кэша.
  

Также полезно периодически проверять целостность файловых систем btrfs с помощью утилит btrfs check (в режиме только для чтения).

Как проверить свою версию​

Для проверки версии ядра и наличия исправления используйте следующие команды:

uname -r
uname -a
cat /proc/version

Сверьте полученную версию с официальными релизами Linux kernel и наличием коммита 0d26249671171ab759cb4fdce673554a690fa655 в истории изменений. Если версия ядра включает этот коммит, система защищена от CVE-2026-80734.

Исправление​

Единственным подтверждённым способом устранения уязвимости является обновление ядра Linux до версии, содержащей исправление.

• Обновление ядра: Установите актуальную версию ядра из официального репозитория дистрибутива или с сайта kernel.org.
  
• Перезагрузка: После установки нового ядра выполните перезагрузку системы для его активации.
  
• Проверка: Убедитесь, что новая версия ядра содержит коммит 0d26249671171ab759cb4fdce673554a690fa655.
  

Не рекомендуется применять частичные патчи или модифицировать исходный код ядра вручную, если это не требуется для специфических окружений.

Временные меры защиты​

Пока не выполнено обновление ядра, можно снизить риск срабатывания уязвимости:

• Избегание btrfs 8 КБ: Если возможно, смонтируйте тома btrfs с размером блока 4 КБ или используйте другую файловую систему.
  
• Ограничение доступа: Ограничьте локальный доступ к системам, использующим btrfs с блоками 8 КБ, до минимально необходимого.
  
• Мониторинг: Усиленный мониторинг системных журналов на предмет падений ядра и ошибок btrfs.
  

Эти меры не устраняют уязвимость, но снижают вероятность её срабатывания.

Как проверить устранение уязвимости​

После обновления ядра выполните следующие шаги для проверки:

1. Проверка версии: Убедитесь, что активное ядро имеет версию, содержащую исправление.
   
2. Тестирование: Если возможно, выполните тест generic/795 в изолированной среде, чтобы убедиться, что падение ядра не воспроизводится.
   
3. Мониторинг: Продолжайте мониторинг системных журналов в течение нескольких дней после обновления, чтобы убедиться в отсутствии аномалий.
   

Если после обновления система стабильно работает и тесты проходят, уязвимость считается устранённой.

Вывод​

CVE-2026-80734 представляет собой серьёзную уязвимость в подсистеме btrfs, способную привести к падению ядра. Хотя вероятность удалённой эксплуатации низка, локальный злоумышленник может использовать её для отказа в обслуживании.

Обновление ядра до актуальной версии является обязательным шагом для защиты систем, использующих btrfs с блоками 8 КБ. Администраторам рекомендуется проверить версии ядра и при необходимости запланировать обновление в ближайшем окне обслуживания.

Официальные источники​

1. NVD — CVE-2026-80734
   
2. FIRST EPSS — CVE-2026-80734
   
3. btrfs: initialize inode mapping flags for cached inodes - kernel/git/stable/linux.git - Linux kernel stable tree
   
4. btrfs: initialize inode mapping flags for cached inodes - kernel/git/stable/linux.git - Linux kernel stable tree
   
5. CVEs — The Linux Kernel documentation
   

История обновлений статьи​

• 04.09.2026 — Опубликована первая версия материала.