22 липня розкрита вразливість CVE-2026-64600 (RefluXFS) в ядрі Linux: умова гонки в підсистемі XFS reflink дає змогу непривілейованому локальному користувачу перезаписати файли, що належать root, і отримати постійний привілейований доступ. Баг присутній у ядрах починаючи з версії 4.11 (2017 рік). За даними дослідників Qualys, умови експлуатації виконуються на стандартних інсталяціях Red Hat Enterprise Linux та похідних дистрибутивів, Fedora Server і Amazon Linux. Виправлення влито в основну гілку ядра 16 липня, вендори почали випускати оновлені ядра. Публічний PoC-експлойт доступний, але експлуатацію «в дикій природі» на момент розкриття не зафіксовано. Єдиний дієвий захід — оновлення ядра з подальшим перезавантаженням.
Механізм вразливості
Вразливість належить до класу TOCTOU (time-of-check-to-time-of-use) — помилка перевірки перед використанням через цикл блокування. Зловмисник клонує файл, що належить root, у свій робочий файл за допомогою системного виклику FICLONE, для якого достатньо права на читання вихідного файлу. Механізм XFS reflink використовує копіювання під час запису (copy-on-write): обидва файли спочатку посилаються на одні й ті самі фізичні блоки диска.
Ядро зчитує відображення даних (data-fork mapping) під блокуванням інода і передає його функції xfs_reflink_fill_cow_hole(), яка знімає це блокування для резервування транзакційного простору. У цей проміжок другий паралельний процес запису може завершити операцію copy-on-write і переназначити клонирований файл на новий блок. Коли перший процес запису повторно захоплює блокування, він оновлює COW-форк, але продовжує використовувати застарілу адресу блоку з data-fork.
Як описано в патчі: «мапінги стають застарілими, щойно ми повторно захоплюємо ILOCK». Застаріла адреса тепер вказує на блок, що належить виключно оригінальному захищеному файлу. XFS вважає блок нерозділюваним і дозволяє прямий запис — дані, призначені для клона зловмисника, потрапляють у цільовий файл root.
Критично важливо: запис через Direct I/O обходить сторінковий кеш і цільовий інод повністю, тому метадані файлу — власник, права, часові мітки, біт setuid — лишаються недоторканими. За даними дослідників, модифікований setuid-root бінарний файл продовжує виконуватися з правами root. Тести не показали ані попереджень ядра, ані записів у журналах. На тестовій машині умову гонки, за повідомленням, вдавалося виграти менш ніж за десять секунд.
Патч зачіпає дві функції — xfs_reflink_fill_cow_hole() і xfs_reflink_fill_delalloc(). Виправлення зберігає значення лічильника ip->i_df.if_seq перед зняттям блокування і перечитує data-fork через xfs_bmapi_read(), якщо лічильник змінився.
Хто перебуває під загрозою
Експлуатація потребує одночасного виконання трьох умов:
- Система працює на ядрі Linux 4.11 або новішому без виправлення RefluXFS.
- Файлова система XFS створена з параметром
reflink=1. - Цільовий файл (доступний на читання) і каталог, доступний зловмиснику на запис, розташовані на одній файловій системі XFS.
За даними Qualys, типові інсталяції таких систем можуть задовольняти ці умови:
- RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, CloudLinux версій 8, 9 і 10
- Fedora Server 31 і новіші
- Amazon Linux 2023 та образи Amazon Linux 2, починаючи з грудня 2022
RHEL 7 не зачеплений — його файлові системи передують підтримці XFS reflink. Дистрибутиви Debian, Ubuntu, SLES та openSUSE за замовчуванням не використовують XFS для кореневої файлової системи і вразливі лише у разі явного вибору XFS з увімкненим reflink під час інсталяції.
Для перевірки виконайте:
xfs_info / | grep reflink=
Результат reflink=1 означає, що друга умова експлуатації виконана. Ту саму перевірку слід провести для всіх змонтованих томів XFS, де захищені файли та каталоги з доступом на запис можуть співіснувати.
Відсутність обхідних шляхів
Qualys повідомляє, що практичних тимчасових заходів не існує. Немає параметра монтування або опції sysctl, яка вимкнула б reflink на вже створеній файловій системі. Під час тестування дослідників SELinux у режимі Enforcing, seccomp, kernel lockdown і межі контейнерів не зупинили експлуатацію. Механізми захисту пам’яті (KASLR, SMEP) непридатні: це запис на рівні блокового пристрою, а не пошкодження пам’яті.
Єдине обмеження — гонка спрацьовує лише якщо цільовий блок файлу не є розділюваним (unshared). Однак, як зазначено в адвизорі, непривілейований користувач може скинути цю умову, наприклад, виконавши chsh, а setuid-root бінарні файли в типових конфігураціях і так не є reflink-копіями.
Роль ІІ виявленні
Qualys заявляє, що вразливість була виявлена за допомогою моделі ШІ — Claude Mythos Preview від Anthropic, якій було запропоновано знайти вразливість, подібну до Dirty COW. За даними компанії, модель локалізувала гонку, написала робочий експлойт для отримання root і підготувала чернетку адвизорі. Дослідники потім відтворили баг на стандартній інсталяції Fedora Server 44, перевірили логіку моделі та координували розкриття з розробниками ядра. Це твердження походить виключно від Qualys і не підтверджене незалежно.
Статус патчів
Red Hat опублікував рекомендації з рейтингом Important для зачеплених потоків RHEL 8, 9 і 10. Еррати почали публікуватися 14 липня — за вісім днів до координованого розкриття: RHSA-2026:39179 і RHSA-2026:39180 для RHEL 8, RHSA-2026:39494 для RHEL 10, з додатковими оновленнями для потоків розширеної підтримки та SAP до 17 липня. Покриття залежить від конкретного потоку — необхідно переконатися в наявності еррати для вашого точного релізу.
Запис у баг-трекері Red Hat було автоматично імпортовано 10 липня під заголовком «kernel: XFS data corruption using reflink» і спочатку описувало проблему як можливе пошкодження даних. Публічний PoC зареєстрований у трекері 22 липня.
За даними трекера 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, включно з їхніми гілками безпеки, досі позначені як вразливі.
Рекомендації
- Пріоритизуйте багатокористувацькі системи та хости, де неперевірений код може виконуватися локально (CI/CD, спільні сервери, скомпрометовані сервіси).
- Встановіть оновлене ядро від вашого вендора. Організаціям, які застосували еррати Red Hat до 22 липня, захист уже забезпечено.
- Перезавантажте систему після встановлення пакета — оновлення не замінює працююче в пам’яті ядро.
- Перевірте, що система завантажилася з виправленим ядром:
uname -r. - Перевірте всі томи XFS на наявність
reflink=1, а не лише кореневу файлову систему.
RefluXFS — вразливість без обхідних шляхів: ні SELinux, ні контейнеризація, ні seccomp не блокують експлуатацію. За наявності публічного PoC і детального опису кроків атаки в розсилці oss-security вікно для безпечного бездіяльності мінімальне. Єдина надійна дія — встановити оновлене ядро і перезавантажити кожен хост з XFS reflink, переконавшись командою uname -r, що система працює на виправленій версії.
