Aggiornamento sicuro del kernel per CVE-2026-98432 su Ubuntu 24.04 con NVIDIA, e un'analisi del bug
Questo porta una macchina Ubuntu 24.04 con una GPU NVIDIA su un kernel che corregge CVE-2026-98432, un use-after-free nel codice IPv4 TCP del kernel. È pensato per una macchina che potresti non riuscire a raggiungere se l'aggiornamento va storto: nulla è considerato affidabile finché non è stato avviato, e un passaggio fallito si interrompe esplicitamente invece di lasciare un host in stato di malfunzionamento.
Preferisci i normali aggiornamenti di Ubuntu se includono la correzione. Questo esiste perché, nell'emergenza per cui è stato scritto, l'unico kernel corretto era una build pre-release nell'archivio staging di Canonical. Il kernel pubblicato più recente, 7.0.0-42, presentava ancora il bug.
Non basarti sul numero di versione. Leggi il codice del kernel in esecuzione con il gate di personal_server:
sudo bash scripts/14_verify_kernel_fixes.sh
Legge il codice macchina del kernel in esecuzione dalla memoria live, e del kernel che GRUB avvia successivamente dalla sua immagine. Nel kernel corretto, inet_sock_destruct e tcp_v4_reqsk_destructor chiamano kvfree_call_rcu. In quello vulnerabile chiamano kfree.
Se fallisce, prova prima la via normale:
sudo apt-get update
sudo apt-get install --only-upgrade linux-generic-hwe-24.04
sudo systemctl reboot
Usa questo repository solo se ciò non comporta un kernel fisso.
Hai bisogno di una tua copia, perché il processo pubblica la sua traccia di audit su Git mentre è in esecuzione. Fai un fork di questo repository e sulla macchina:
git clone <your fork> && cd <it>
kernel-upgrade/install.sh
sudo systemctl reboot
Consenti circa 8 minuti per i riavvii. La macchina si riavvia da sola altre due volte e non richiede nulla da parte tua:
uname -r # must print 7.0.0-43-generic
python3 -I kernel-upgrade/upgrade.py status # must say complete
Se la macchina non è compatibile, l'installer spiega il motivo e non modifica nulla. kernel-upgrade/PROCEDURE.md contiene ciò di cui ha bisogno l'host, ogni errore e cosa fare al riguardo, e il confine di crash.
| Avvio | Chi lo avvia | Kernel | Cosa succede |
|---|---|---|---|
| 1 | Tu | Un kernel noto per funzionare qui | Dimostra che GRUB può scrivere su questo disco, quindi un avvio una tantum è davvero una tantum |
| 2 | Il processo, una volta | -43, una sola volta | Legge la correzione dalla memoria del kernel e verifica tutto ciò che l'host aveva prima. Un panic ritorna da solo al kernel noto come funzionante |
| 3 | Il processo, una volta | -43, tramite GRUB stock | Dimostra lo stato finale, con GRUB stock ripristinato e ogni altro kernel rimosso |
Cosa garantisce:
complete significa dimostrato. Questo stato viene raggiunto solo dopo un avvio tramite lo stato finale di GRUB e del kernel, e il record finale raggiunge Git prima che lo stato venga salvato.lock.json dice cosa installare e non contiene nulla su alcuna macchina. Il fallback, le liste di rimozione e la baseline di salute sono tutti letti dall'host e pubblicati prima della prima modifica.PROCEDURE.md. L'avvio successivo continua o si ferma esplicitamente.kernel-upgrade/vm/final-run.sh costruisce da zero macchine di test UEFI, con un disco NVMe emulato da 4 TB, ed esegue al loro interno l'installer esatto. test-report.json registra gli hash di ciò che ha superato i test, e install.sh rifiuta di essere eseguito se il codice differisce da quel report.
I 24 scenari coprono interruzioni di corrente reali durante i pacchetti, durante la purge finale e dopo il record finale, kernel panic e blocchi, GitHub che va giù in ogni fase, e una macchina che deve essere rifiutata. from-zero costruisce una macchina con lo script reale di personal_server dall'archivio reale di Ubuntu, vede il gate rifiutarla, la aggiorna e vede il gate superare il controllo. from-zero richiede un clone di personal_server accanto a questo repository.
Ciò che le VM non possono mostrare è elencato in PROCEDURE.md. Il principale è il firmware reale, che l'avvio 1 verifica sulla macchina stessa.
Questo è stato eseguito su un server esposto a Internet con un disco NVMe da 4 TB e una RTX 5090 il 2026-11-02. Quella macchina non ha console remota, solo un interruttore di alimentazione sulla rete. Il primo avvio tramite GRUB stock ha superato ogni controllo, con 7.0.0-43 come unico kernel e la correzione confermata nella memoria del kernel in esecuzione.
La prima versione di questo processo ha funzionato lì ma non era corretta. systemd l'ha terminata nei suoi ultimi millisecondi, perché eliminava il proprio file unit mentre era in esecuzione. Si dichiarava inoltre complete prima che GRUB stock fosse stato avviato, e aveva i dettagli di quella macchina incorporati. Questo repository è la ricostruzione. Revisioni indipendenti hanno poi trovato ulteriori difetti reali prima che venisse eseguito di nuovo, incluso un controllo che avrebbe bloccato ogni host NVMe reale dopo che i suoi pacchetti erano stati modificati.
├── ANALYSIS.md what the bug is, what MPTCP changes, and the limits of that
├── upstream-fix.diff the two-line upstream fix
├── filter/ an interim packet filter. It reduces exposure and isn't a fix
└── kernel-upgrade/
├── PROCEDURE.md the full procedure, failure table and crash boundary
├── install.sh the entry point
├── upgrade.py the controller and the audit publisher
├── lock.json what to install, with hashes
├── cuda-probe.c a real GPU allocation, for the health check
├── test_upgrade.py logic tests against a real Git remote
├── test-report.json what passed, and the exact bytes it covered
├── test-evidence/ the journal of each VM scenario
└── vm/ the VM test harness
Il codice è rilasciato sotto la Unlicense. I pacchetti mantengono le proprie licenze. La release contiene i pacchetti kernel di Canonical e dkms, perché l'archivio di staging elimina le build precedenti. I pacchetti NVIDIA non sono ridistribuiti qui: provengono dal tuo archivio Ubuntu.