Copy.Fail — больше чем LPE

@secinfosex

Свежая 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.5 секунд.

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 процессов.

PoC

Модификация инструкции в работающем процессе:

// test_loop.c
// gcc -o /tmp/test_loop /tmp/test_loop.c

int check() { return 42; }
int main() {
    while(1) { printf("check() = %d\n", check()); sleep(2); }
}

$ objdump -d /tmp/test_loop | grep -A1 "<check>"
  114d: b8 2a 00 00 00  mov $0x2a,%eax     ← return 42

Перезаписываем mov $0x2a → mov $0x539 (offset 0x114d = 4429 decimal):

$ python3 copy_fail_write.py /tmp/test_loop 4429 b8390500

Результат на работающем процессе:

check() = 42
check() = 42
check() = 1337    ← код изменён без остановки процесса
check() = 1337

Тестировано на Debian 6.1.0-25, x86_64. Процесс не останавливался, ptrace не использовался, /proc/PID/mem не открывался.

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

Незаметный и необнаруживаемый, что немного усложняет и без того эпичный баг.

Какие механизмы защиты это обходит

Все задокументированные подходы (MITRE DET0203, DET0508, Tracee TRC-1024, Akamai guide) мониторят ptrace, /proc/PID/mem, process_vm_writev. Page cache injection не использует ни один из этих механизмов — атакующий процесс работает только с файлом (AF_ALG socket + splice).

Теперь ловить нужно здесь.

YAMA ptrace_scope — ограничивает ptrace. Не применимо, ptrace не используется.

Seccomp — зависит от профиля. Docker default и Kubernetes PSS Restricted не блокируют AF_ALG (подтверждено Juliet Security). Профиль, явно блокирующий socket(AF_ALG, ...), предотвращает атаку.

auditd ptrace/procfs rules — не срабатывают (ptrace и /proc/PID/mem не используются).

Невидимость для файлового мониторинга

Copy Fail не вызывает write() на целевом файле.
Модификация page cache происходит внутри crypto subsystem через scatterwalk_map_and_copy().

inotify — не видит модификацию

$ inotifywait -m /tmp/copyfail_test.txt &
$ python3 copy_fail_write.py /tmp/copyfail_test.txt 0 --text "PWND"

/tmp/copyfail_test.txt OPEN
/tmp/copyfail_test.txt ACCESS
/tmp/copyfail_test.txt CLOSE_NOWRITE,CLOSE

Событие MODIFY не генерируется. Зафиксированы только OPEN, ACCESS, CLOSE_NOWRITE — нормальные события чтения. Инструменты, зависящие от inotify (systemd path units, часть EDR), не получают уведомления об изменении.

mtime/ctime — не обновляются

Modify: 2026-05-01 00:13:34    # до Copy Fail
Modify: 2026-05-01 00:13:34    # после — без изменений

Обратимость

Модификация page cache обратима через posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) — ядро сбрасывает страницы из кэша, следующее чтение загружает оригинальные данные с диска. Это делается без привилегий. После сброса: содержимое файла восстановлено, хэши совпадают с baseline, mtime не менялся, inotify не срабатывал.

Полный цикл (inject → use → erase) похоже невидим для средств мониторинга.

Telegram: @secinfosex