22 июля 2026 года исследовательское подразделение Qualys Threat Research Unit опубликовало отчёт об уязвимости, получившей имя RefluXFS и идентификатор CVE-2026-64600. Издание The Hacker News первым рассказало об этой истории, а 24 июля материал дополнили комментарием от самих исследователей Qualys. Суть проблемы простая и неприятная одновременно: непривилегированный локальный пользователь может переписать файлы, принадлежащие root, на файловой системе XFS и получить постоянный root-доступ, который переживает перезагрузку системы.
Технически подмена происходит на уровне блочного слоя, а не через привычную для таких атак память процесса. После атаки владелец файла, права доступа, временные метки и даже setuid-бит остаются нетронутыми — модифицированный setuid-root бинарник как ни в чём не бывало продолжает запускаться от имени root. Никакого предупреждения ядра или записи в логе при этом не появляется. В тестах Qualys гонка выигрывалась меньше чем за 10 секунд, а демонстрация атаки была проведена на свежеустановленном RHEL 10.2 со стандартными настройками — пароль root там просто обнулили.
Механизм назвали «stale mapping», устаревшее отображение. Атакующий клонирует файл, принадлежащий root, во временный файл с помощью FICLONE — для этого достаточно прав на чтение исходника. Затем он запускает гонку из параллельных операций записи O_DIRECT против этого клона. XFS-рефлинки используют copy-on-write, и оба файла первоначально указывают на одни и те же физические блоки. Ядро читает отображение data-fork под блокировкой инода (ILOCK), а затем вызывает функцию xfs_reflink_fill_cow_hole(), которая на время снимает и снова берёт эту блокировку, чтобы зарезервировать место под транзакцию. Именно в этом окне второй писатель успевает завершить операцию COW и переназначить клонированный файл на новый блок. Когда первый писатель снова захватывает блокировку, он обновляет только COW-fork, но продолжает использовать старое, устаревшее отображение data-fork. В патче для апстрима это описано прямо: «отображения становятся устаревшими сразу же, как только мы повторно захватываем ILOCK». В итоге XFS считает блок неразделяемым и разрешает прямую запись — но данные, предназначенные для клона атакующего, попадают в целевой файл. Классифицировали это как ошибку типа check-then-use через цикл блокировки.
The Hacker News добавил ещё одну деталь: патч затрагивает не одну, а две вспомогательные функции — xfs_reflink_fill_cow_hole() и xfs_reflink_fill_delalloc(). Вторая страдает от того же порока с циклом блокировки, но в самом бюллетене Qualys не упоминается. Глава Threat Research Unit Saeed Abbasi рассказал изданию, что модель ИИ нашла оба пути одновременно именно из-за их схожести. Исправление сводится к тому, что перед освобождением блокировки делается снимок счётчика ip->i_df.if_seq, и если он изменился, data-fork перечитывается через xfs_bmapi_read(). Прямой ввод-вывод обходит страничный кэш и не имеет хука для повторной проверки — запись просто попадает на диск, минуя целевой инод, поэтому его метаданные никогда не меняются.
Корни бага уходят в ядро версии 4.11, выпущенное в 2017 году. Коммит с тегом Fixes: получил имя 3c68d44a2b49, запрос на бэкпорт в стабильную ветку помечен как v4.11, а сам фикс смержили 16 июля 2026 года. Вендоры уже начали поставлять ядра с обратным портированием патча.
Для эксплуатации нужно одновременное выполнение трёх условий: система работает на Linux 4.11 или новее без применённого исправления, файловая система XFS создана с опцией reflink=1, и читаемая цель вместе с директорией, доступной атакующему на запись, находятся на одной и той же файловой системе XFS. Под удар попадают Red Hat Enterprise Linux 8, 9 и 10 вместе с производными дистрибутивами, Fedora Server начиная с версии 31, Amazon Linux 2023, а также образы Amazon Linux 2 начиная с декабря 2022 года. RHEL 7 не затронут вовсе — просто потому что вышел раньше появления поддержки reflink в XFS. Debian, Ubuntu, SLES и openSUSE по умолчанию не используют XFS как корневую файловую систему, так что рискуют только те администраторы, кто вручную выбрал XFS с включённым reflink при установке.
Проверить систему можно одной командой: xfs_info / | grep reflink=. Если в выводе значится reflink=1, второе условие эксплуатации выполнено, и стоит также прогнать эту же проверку на любых других смонтированных томах XFS, где сосуществуют защищённый файл и доступная атакующему для записи директория. Qualys советует в первую очередь патчить системы, открытые внешним пользователям, и многопользовательские хосты — любую машину с XFS и включённым reflink, где локально может выполняться недоверенный код: через shell, задачу CI или скомпрометированный сервис.
Здесь плохие новости: отключить рефлинки XFS после создания файловой системы не получится ни через опцию монтирования, ни через sysctl. По данным Qualys, практического обходного пути или временного митигирования просто не существует. В тестах не сработала ни SELinux в режиме Enforcing, ни seccomp, ни kernel lockdown, ни границы контейнеров. Защиты памяти вроде KASLR и SMEP тоже бессильны — это запись на уровне блочного устройства, а не повреждение памяти. Есть только одно частичное ограничение: гонка срабатывает лишь если целевой блок изначально не разделён с другим файлом. Файл, который администратор уже скопировал через reflink, этим способом не тронуть. Но в бюллетене отмечено, что непривилегированный пользователь способен сбросить это условие простой командой chsh, а setuid-root бинарники в реальности редко бывают уже рефлинкнуты, так что на практике это ограничение почти не спасает.
Отдельного внимания заслуживает то, как уязвимость вообще нашли. Qualys использовала Claude Mythos Preview — модель Anthropic с ограниченным доступом, находящуюся на переднем крае разработки. Задача звучала просто: «найди уязвимость, похожую на Dirty COW». Модель самостоятельно обнаружила гонку, написала работающий эксплойт для получения root и составила черновик технического бюллетеня. После этого исследователи Qualys воспроизвели баг на чистой установке Fedora Server 44, проверили логику рассуждений модели и скоординировали раскрытие информации с разработчиками апстрима. Saeed Abbasi признался, что команда почти не правила черновик ИИ: переписали три заглушки перед обращением к сопровождающим — примечание в последний момент, благодарности и таймлайн, — и заменили эпиграфы, убрав цитаты из телесериалов, которые вставил ИИ, на строки из песен. «Больше ничего», — сказал он.
RefluXFS не первая находка Qualys за последнее время. Днём раньше, накануне раскрытия информации о RefluXFS, компания опубликовала данные об уязвимости в snap-confine на Ubuntu Desktop — CVE-2026-8933, две гонки, позволяющие получить локальный root на системах со стандартной установкой. А в мае 2026 года Qualys нашла девятилетний баг в проверках ptrace ядра Linux.
Реакция вендоров пока неравномерная. Red Hat выпустила бюллетени с рейтингом Important для затронутых потоков RHEL 8, 9 и 10, но покрытие зависит от конкретного релиза — пользователям нужно проверять наличие рекомендации именно для своей версии. Те, кто регулярно ставил плановые обновления, оказались защищены ещё до того, как уязвимости присвоили имя. В баг-трекере Red Hat запись называется «kernel: XFS data corruption using reflink», была автоматически импортирована 10 июля и поначалу описывалась просто как возможное повреждение данных при рефлинкинге. 22 июля в трекере зафиксировали публичное proof-of-concept, со ссылкой на бюллетень, опубликованный в рассылке oss-security. The Hacker News запросил у Red Hat комментарий по оценке влияния уязвимости, ответ на момент публикации материала ещё не поступил.
У Debian по состоянию на 23 июля картина смешанная. В ветке trixie-security проблему исправили в ядре 6.12.96-1, в unstable — в версии 7.1.4-1. При этом базовое ядро Trixie 6.12.94-1, ядро Forky 7.1.3-1, а также Bookworm и Bullseye вместе со своими security-ветками по-прежнему числятся уязвимыми.
Что касается самого эксплойта — Qualys не опубликовала отдельный код для атаки. Saeed Abbasi отверг формулировку «публичный PoC», назвав раздел бюллетеня про эксплуатацию «просто обзором механизма атаки». Компания заявила, что не намерена выпускать рабочий эксплойт, хотя передала его сопровождающим XFS для воспроизведения бага и проверки исправления. На момент публикации ни один вендор не сообщал об эксплуатации уязвимости в реальных условиях. Пользователям, которых касается проблема, рекомендуется установить патч от вендора, обязательно перезагрузить систему — само по себе обновление пакета не заменяет ядро, уже работающее в памяти, — и после перезагрузки убедиться, что запущено исправленное ядро.
Технически подмена происходит на уровне блочного слоя, а не через привычную для таких атак память процесса. После атаки владелец файла, права доступа, временные метки и даже setuid-бит остаются нетронутыми — модифицированный setuid-root бинарник как ни в чём не бывало продолжает запускаться от имени root. Никакого предупреждения ядра или записи в логе при этом не появляется. В тестах Qualys гонка выигрывалась меньше чем за 10 секунд, а демонстрация атаки была проведена на свежеустановленном RHEL 10.2 со стандартными настройками — пароль root там просто обнулили.
Механизм назвали «stale mapping», устаревшее отображение. Атакующий клонирует файл, принадлежащий root, во временный файл с помощью FICLONE — для этого достаточно прав на чтение исходника. Затем он запускает гонку из параллельных операций записи O_DIRECT против этого клона. XFS-рефлинки используют copy-on-write, и оба файла первоначально указывают на одни и те же физические блоки. Ядро читает отображение data-fork под блокировкой инода (ILOCK), а затем вызывает функцию xfs_reflink_fill_cow_hole(), которая на время снимает и снова берёт эту блокировку, чтобы зарезервировать место под транзакцию. Именно в этом окне второй писатель успевает завершить операцию COW и переназначить клонированный файл на новый блок. Когда первый писатель снова захватывает блокировку, он обновляет только COW-fork, но продолжает использовать старое, устаревшее отображение data-fork. В патче для апстрима это описано прямо: «отображения становятся устаревшими сразу же, как только мы повторно захватываем ILOCK». В итоге XFS считает блок неразделяемым и разрешает прямую запись — но данные, предназначенные для клона атакующего, попадают в целевой файл. Классифицировали это как ошибку типа check-then-use через цикл блокировки.
The Hacker News добавил ещё одну деталь: патч затрагивает не одну, а две вспомогательные функции — xfs_reflink_fill_cow_hole() и xfs_reflink_fill_delalloc(). Вторая страдает от того же порока с циклом блокировки, но в самом бюллетене Qualys не упоминается. Глава Threat Research Unit Saeed Abbasi рассказал изданию, что модель ИИ нашла оба пути одновременно именно из-за их схожести. Исправление сводится к тому, что перед освобождением блокировки делается снимок счётчика ip->i_df.if_seq, и если он изменился, data-fork перечитывается через xfs_bmapi_read(). Прямой ввод-вывод обходит страничный кэш и не имеет хука для повторной проверки — запись просто попадает на диск, минуя целевой инод, поэтому его метаданные никогда не меняются.
Корни бага уходят в ядро версии 4.11, выпущенное в 2017 году. Коммит с тегом Fixes: получил имя 3c68d44a2b49, запрос на бэкпорт в стабильную ветку помечен как v4.11, а сам фикс смержили 16 июля 2026 года. Вендоры уже начали поставлять ядра с обратным портированием патча.
Для эксплуатации нужно одновременное выполнение трёх условий: система работает на Linux 4.11 или новее без применённого исправления, файловая система XFS создана с опцией reflink=1, и читаемая цель вместе с директорией, доступной атакующему на запись, находятся на одной и той же файловой системе XFS. Под удар попадают Red Hat Enterprise Linux 8, 9 и 10 вместе с производными дистрибутивами, Fedora Server начиная с версии 31, Amazon Linux 2023, а также образы Amazon Linux 2 начиная с декабря 2022 года. RHEL 7 не затронут вовсе — просто потому что вышел раньше появления поддержки reflink в XFS. Debian, Ubuntu, SLES и openSUSE по умолчанию не используют XFS как корневую файловую систему, так что рискуют только те администраторы, кто вручную выбрал XFS с включённым reflink при установке.
Проверить систему можно одной командой: xfs_info / | grep reflink=. Если в выводе значится reflink=1, второе условие эксплуатации выполнено, и стоит также прогнать эту же проверку на любых других смонтированных томах XFS, где сосуществуют защищённый файл и доступная атакующему для записи директория. Qualys советует в первую очередь патчить системы, открытые внешним пользователям, и многопользовательские хосты — любую машину с XFS и включённым reflink, где локально может выполняться недоверенный код: через shell, задачу CI или скомпрометированный сервис.
Здесь плохие новости: отключить рефлинки XFS после создания файловой системы не получится ни через опцию монтирования, ни через sysctl. По данным Qualys, практического обходного пути или временного митигирования просто не существует. В тестах не сработала ни SELinux в режиме Enforcing, ни seccomp, ни kernel lockdown, ни границы контейнеров. Защиты памяти вроде KASLR и SMEP тоже бессильны — это запись на уровне блочного устройства, а не повреждение памяти. Есть только одно частичное ограничение: гонка срабатывает лишь если целевой блок изначально не разделён с другим файлом. Файл, который администратор уже скопировал через reflink, этим способом не тронуть. Но в бюллетене отмечено, что непривилегированный пользователь способен сбросить это условие простой командой chsh, а setuid-root бинарники в реальности редко бывают уже рефлинкнуты, так что на практике это ограничение почти не спасает.
Отдельного внимания заслуживает то, как уязвимость вообще нашли. Qualys использовала Claude Mythos Preview — модель Anthropic с ограниченным доступом, находящуюся на переднем крае разработки. Задача звучала просто: «найди уязвимость, похожую на Dirty COW». Модель самостоятельно обнаружила гонку, написала работающий эксплойт для получения root и составила черновик технического бюллетеня. После этого исследователи Qualys воспроизвели баг на чистой установке Fedora Server 44, проверили логику рассуждений модели и скоординировали раскрытие информации с разработчиками апстрима. Saeed Abbasi признался, что команда почти не правила черновик ИИ: переписали три заглушки перед обращением к сопровождающим — примечание в последний момент, благодарности и таймлайн, — и заменили эпиграфы, убрав цитаты из телесериалов, которые вставил ИИ, на строки из песен. «Больше ничего», — сказал он.
RefluXFS не первая находка Qualys за последнее время. Днём раньше, накануне раскрытия информации о RefluXFS, компания опубликовала данные об уязвимости в snap-confine на Ubuntu Desktop — CVE-2026-8933, две гонки, позволяющие получить локальный root на системах со стандартной установкой. А в мае 2026 года Qualys нашла девятилетний баг в проверках ptrace ядра Linux.
Реакция вендоров пока неравномерная. Red Hat выпустила бюллетени с рейтингом Important для затронутых потоков RHEL 8, 9 и 10, но покрытие зависит от конкретного релиза — пользователям нужно проверять наличие рекомендации именно для своей версии. Те, кто регулярно ставил плановые обновления, оказались защищены ещё до того, как уязвимости присвоили имя. В баг-трекере Red Hat запись называется «kernel: XFS data corruption using reflink», была автоматически импортирована 10 июля и поначалу описывалась просто как возможное повреждение данных при рефлинкинге. 22 июля в трекере зафиксировали публичное proof-of-concept, со ссылкой на бюллетень, опубликованный в рассылке oss-security. The Hacker News запросил у Red Hat комментарий по оценке влияния уязвимости, ответ на момент публикации материала ещё не поступил.
У Debian по состоянию на 23 июля картина смешанная. В ветке trixie-security проблему исправили в ядре 6.12.96-1, в unstable — в версии 7.1.4-1. При этом базовое ядро Trixie 6.12.94-1, ядро Forky 7.1.3-1, а также Bookworm и Bullseye вместе со своими security-ветками по-прежнему числятся уязвимыми.
Что касается самого эксплойта — Qualys не опубликовала отдельный код для атаки. Saeed Abbasi отверг формулировку «публичный PoC», назвав раздел бюллетеня про эксплуатацию «просто обзором механизма атаки». Компания заявила, что не намерена выпускать рабочий эксплойт, хотя передала его сопровождающим XFS для воспроизведения бага и проверки исправления. На момент публикации ни один вендор не сообщал об эксплуатации уязвимости в реальных условиях. Пользователям, которых касается проблема, рекомендуется установить патч от вендора, обязательно перезагрузить систему — само по себе обновление пакета не заменяет ядро, уже работающее в памяти, — и после перезагрузки убедиться, что запущено исправленное ядро.