CVE-2026-98432

Scritto da DeepSeek.

Un semplice server TCP IPv4 è vulnerabile. MPTCP non è il fattore scatenante.

Abbiamo compilato Linux 6.18.55 dal tarball di rilascio e fatto sì che il kernel leggesse memoria liberata su un normale listener IPPROTO_TCP. KASAN lo ha segnalato due volte. Nessun socket MPTCP è mai stato creato, e in un'esecuzione MPTCP era disattivato nel kernel.

Lo stesso bug fa sì che il kernel copi byte da un oggetto liberato nella risposta che invia indietro. Questo è la primitiva necessaria per un attacco a KASLR, e l'abbiamo osservato accadere in un lavoro non pubblicato. Non abbiamo costruito una fuga di indirizzi del kernel, e non abbiamo dimostrato una scrittura.

Ciò che è dimostrato qui, con codice e log: l'use-after-free è reale, il TCP standard lo raggiunge, e la correzione upstream lo blocca.

Le esecuzioni

Kernel	MPTCP	Tentativi	Tempo	Risultato
6.18.55, senza correzione	non usato	134.955	34 s	KASAN use-after-free
6.18.55, senza correzione	disattivato	191.431	80 s	KASAN use-after-free
6.18.55 + correzione	non usato	439.316	411 s	pulito

Quanto è difficile da colpire?

Molto difficile. Con KASAN il lettore è lento, quindi il bug si manifesta entro qualche centinaio di migliaia di tentativi. Su un kernel normale è molto più raro: su circa 48 milioni di tentativi abbiamo visto due eventi, entrambi all'interno degli stessi cinque secondi.

Sono troppo pochi per stabilire un tasso. Il massimo che affermeremo è un limite di circa 1e-7 per tentativo, e anche questo è il caso migliore, perché il nostro harness forza i due pacchetti su due CPU e una NIC reale di solito invia un flusso a una sola CPU.

Quindi un'esecuzione pulita non significa un kernel sicuro. Leggi le sezioni 5.2 e 6 di ANALYSIS.md prima di citare qualsiasi numero.

Il bug in parole semplici

Un server TCP riceve un SYN. Il SYN trasporta un'opzione IPv4 (Record Route o Timestamp). Il kernel salva quelle opzioni sul request socket.

Arriva un secondo SYN per la stessa connessione. Il kernel costruisce un SYNACK per esso e legge le opzioni salvate.

Allo stesso tempo la handshake termina. Il child socket ottiene lo stesso puntatore, non una copia. Il server chiude il child, e il kernel libera le opzioni con un semplice kfree().

Il codice del SYNACK sta ancora leggendo quella memoria. Questo è l'use-after-free. La stessa lettura è ciò che inserisce i byte liberati nel pacchetto.

Cosa non è questo repo

È un trigger di bug, non un exploit. Non fa trapelare indirizzi del kernel, non scrive nella memoria del kernel e non ottiene i privilegi di root. Mostra il kernel che legge memoria liberata; KASAN è il giudice.

Il repo si ferma qui di proposito. Le fasi successive sono state sviluppate privatamente e non sono pubblicate qui.

Riprodurlo

scripts/get-kernel.sh              # fetch 6.18.55, sha256 checked, into linux/
scripts/build-kernel.sh vuln       # KASAN kernel, no fix
scripts/build-kernel.sh patched    # KASAN kernel, with the fix
scripts/build-harness.sh           # builds harness/init + initramfs
scripts/run.sh vuln 90 selftest    # checks the wiring only
scripts/run.sh vuln 600            # expect a KASAN report
scripts/run.sh patched 600         # expect nothing

Ti servono gcc, make, bison, flex, bc e qemu-system-x86_64. KVM aiuta molto. La VM richiede 2 GB di RAM e 8 vCPU.

Una singola esecuzione potrebbe non mostrare nulla. Questo non è una prova che il kernel sia sicuro. Eseguila più volte e leggi le avvertenze in ANALYSIS.md.

Verifica il tuo kernel

Non fidarti della stringa di versione. Guarda il codice nel binario.

scripts/check-free-sites.py

Individua i due siti liberi nel kernel in esecuzione e mostra quale funzione chiamano: kfree (difettosa) o kvfree_call_rcu (corretta).

Sulla macchina su cui è stato scritto (6.18.59_1) entrambi i siti usano kvfree_call_rcu, quindi quel kernel è corretto.

Chi è esposto

Un host è esposto se tutte e tre le condizioni sono vere:

1. è in ascolto su IPv4 TCP, e
2. il peer invia un SYN con opzioni IP, e
3. il programma chiude presto il socket accettato.

L'attaccante controlla il punto 2. Quindi la maggior parte dei server internet è esposta, e "non usiamo MPTCP" non aiuta.

Due note:

• accept_source_route=0 non ti protegge. Blocca solo il source routing, non Record Route o Timestamp.
• Se non puoi ancora applicare la patch, scarta i SYN in ingresso che trasportano opzioni IP. Così il kernel non salva mai le opzioni per il socket della richiesta. Applicare la patch è meglio.

File

Percorso	Cosa
ANALYSIS.md	il report completo: percorso del sorgente, metodo, risultati, limiti
harness/	il trigger del bug che viene eseguito come /init in QEMU
patches/	la correzione upstream, usata per la build di controllo
scripts/	helper per fetch, build, esecuzione e verifica
evidence/	report KASAN, log di esecuzione, confronto delle build

Ambito

Solo kernel di test, e solo quelli di tua proprietà. Nulla di quanto qui presente dovrebbe essere indirizzato verso sistemi che non controlli.

Licenza

MIT per il nostro codice e i nostri testi. patches/ contiene un commit del kernel Linux e resta sotto GPL-2.0. Vedi LICENSE.