CVE-2026-98975 in Linux
Сводка
по VulDB • 23.10.2026
В ядре Linux была устранена следующая уязвимость:
xfs: прекратить обмен флагами reflink при обмене отображениями (mappings)
Когда операция обмена охватывает оба файла от смещения 0 до i_disk_size, функция xmi_can_exchange_reflink_flags() предполагает, что все отображения были перемещены, и передает флаг reflink другому файлу.
Это предположение неверно. Файл может по-прежнему владеть общими блоками за пределами i_disk_size, например, после того как EXCHANGE_RANGE_TO_EOF установит меньший размер без отмены маппинга (unmapping). Флаг все равно сбрасывается, и следующая запись в такой блок происходит на месте (in place), а не через механизм Copy-on-Write (CoW), что приводит к повреждению другого файла, с которым он делится.
Коммит a23eca88448e ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN") исправил один из случаев этой проблемы. Вместо добавления еще одного специального случая следует прекратить перемещение флагов. Функция xfs_exchmaps_ensure_reflink() уже устанавливает флаг для обоих inode до начала обмена, поэтому оба просто сохраняют его.
Ничто больше не устанавливает CLEAR_INO{1,2}_REFLINK. Намерения (intents), записанные более старыми ядрами, могут по-прежнему содержать их; восстановление уже маскирует их, поэтому они остаются в маске формата журнала и игнорируются.
XFS_IOC_SWAPEXT имеет ту же проблему: он перемещает флаг reflink с одного inode на другой вместе с экстентами (extents). Простого удаления этого недостаточно здесь: путь обмена заранее помечает оба inode через xfs_exchmaps_ensure_reflink(), но swapext не имеет такого шага, поэтому inode, получающий общие экстенты, останется без флага. Вместо этого следует установить его для обоих inode и убедиться, что у обоих есть ветка CoW (Copy-on-Write), поскольку от inode с установленным флагом reflink ожидается наличие такой ветки.
Теперь флаг сохраняется до тех пор, пока FALLOC_FL_UNSHARE_RANGE, xfs_scrub или усечение файла в ноль не снимут его.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.