Copy.Fail (CVE-2026-31431) — больше чем LPE

В сфере искусственного интеллекта произошло заметное событие. akirsanov 17 минут назад Copy. Fail (CVE-2026-31431) — больше чем LPE Уровень сложности Средний Время на прочтение 3 мин Охват и читатели 630 Linux * DevOps * Информационная безопасность * Аналитика Свежая CVE-2026-31431 только набирает обороты, и тут я хочу показать, почему это не совсем обычная LPE. Copy Fail как примитив Process Injection через Page Cache Оригинальный PoC модифицирует setuid binary перед execve и получает root.

Второй публичный PoC подменяет id у текущего юзера на 0000. Хорошие, рабочие LPE, дающие рута. Но исследуя дополнительные свойства этого примитива я обнаружил несколько эффектов, не описанных в оригинальном disclosure: Copy Fail позволяет модифицировать код уже запущенного процесса — без ptrace и без взаимодействия с процессом.

Технические детали

Без execve для запуска кода. Модификация невидима для inotify, не обновляет mtime файла, невидима для auditd и других стандартных инструментов отслеживания инжекта в процесс. Модифицировать можно не только 4 байта, в цикле примитивами был модифицирован файл в 100 Кб данных за 6.

Live Code Injection в работающий процесс Исполняемый файл загружается через mmap(file, MAP_PRIVATE, PROT_READ|PROT_EXEC). text segment доступен только на чтение — процесс в него не пишет, COW не происходит. PTE указывает на page cache page файла.

Copy Fail модифицирует эту page cache page через crypto subsystem (AF_ALG + splice + authencesn scratch write). Процесс видит изменённый код при следующем исполнении инструкции с модифицированной page. Аналогичный механизм использовал Dirty Pipe (CVE-2022-0847) — запись в page cache через splice.

Отраслевые последствия

Разница: Dirty Pipe модифицировал pipe buffer flags, Copy Fail использует scratch write в authencesn. Класс атаки один — эксплуатация разделяемости page cache между файловым кэшем и memory mappings процессов. Max Kellerman ещё в 2022, раскрывая Dirty Pipe, отметил что page cache write позволяет «inject code into arbitrary processes».

Fail это сработало на практике, и заодно обнаружилось, что стандартный Linux detection stack не очень готов к этому. PoC Результат на работающем процессе: check() = 42 check() = 42 check() = 1337 ← код изменён без остановки процесса check() = 1337 Протестировано на Debian 6. 0-25, x86_64 и aarch64 Процесс не останавливался, ptrace не использовался, /proc/PID/mem не открывался.

На уязвимых системах это рабочий способ инжекта в процесс в Linux. Detection stack для process injection не покрывает этот случай. Синие должны мониторить AF_ALG, не только ptrace.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.