Свежая CVE-2026-31431 только набирает обороты, и тут я хочу показать, почему это не совсем обычная LPE.

Copy Fail как примитив Process Injection через Page Cache

Но исследуя дополнительные свойства этого примитива я обнаружил несколько эффектов, не описанных в оригинальном disclosure:

1. Copy Fail позволяет модифицировать код уже запущенного процесса — без ptrace и без взаимодействия с процессом. Без execve для запуска кода.

2. Модификация невидима для inotify, не обновляет mtime файла, невидима для auditd и других стандартных инструментов отслеживания инжекта в процесс.

3. Модифицировать можно не только 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.

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

// 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

На уязвимых системах это рабочий способ инжекта в процесс в 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).

Теперь ловить нужно и AF_ALG сокет.

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