Sicheres Kernel-Upgrade für CVE-2026-98432 unter Ubuntu 24.04 mit NVIDIA und eine Analyse des Bugs
Dies versetzt einen Ubuntu-24.04-Rechner mit einer NVIDIA-GPU auf einen Kernel, der CVE-2026-98432 behebt, eine Use-after-free-Schwachstelle im IPv4-TCP-Code des Kernels. Es ist für einen Rechner gedacht, den man möglicherweise nicht mehr erreichen kann, wenn das Upgrade schiefgeht: Nichts wird als vertrauenswürdig angesehen, bevor es gebootet hat, und ein fehlgeschlagener Schritt bricht explizit ab, statt einen defekten Host zu hinterlassen.
Bevorzuge Ubuntus normale Updates, wenn sie den Fix enthalten. Dies existiert, weil in dem Notfall, für den es geschrieben wurde, der einzige behobene Kernel ein Vorab-Build im Staging-Archiv von Canonical war. Der neueste veröffentlichte Kernel, 7.0.0-42, wies den Fehler noch auf.
Verlass dich nicht auf die Versionsnummer. Lies den Code des laufenden Kernels selbst mit dem Gate von personal_server:
sudo bash scripts/14_verify_kernel_fixes.sh
Es liest den Maschinencode des laufenden Kernels aus dem Live-Speicher und den des Kernels, den GRUB als Nächstes aus seinem Image startet. Im gepatchten Kernel rufen inet_sock_destruct und tcp_v4_reqsk_destructor kvfree_call_rcu auf. Im verwundbaren rufen sie kfree auf.
Wenn es fehlschlägt, versuchen Sie zuerst den normalen Weg:
sudo apt-get update
sudo apt-get install --only-upgrade linux-generic-hwe-24.04
sudo systemctl reboot
Verwenden Sie dieses Repository nur, wenn das kein festes Kernel mitbringt.
Sie benötigen eine eigene Kopie, da der Prozess während der Ausführung seinen Prüfpfad in Git veröffentlicht. Forken Sie dieses Repository und führen Sie auf der Maschine Folgendes aus:
git clone <your fork> && cd <it>
kernel-upgrade/install.sh
sudo systemctl reboot
Für die Neustarts sollten Sie etwa 8 Minuten einplanen. Die Maschine startet noch zweimal selbst neu und benötigt nichts von Ihnen:
uname -r # must print 7.0.0-43-generic
python3 -I kernel-upgrade/upgrade.py status # must say complete
Wenn die Maschine nicht passt, sagt das Installationsprogramm warum und ändert nichts. kernel-upgrade/PROCEDURE.md enthält, was der Host benötigt, jeden Fehler und was dagegen zu tun ist, sowie die Absturzgrenze.
| Boot | Wer startet ihn | Kernel | Was passiert |
|---|---|---|---|
| 1 | Du | Ein Kernel, der hier bekanntermaßen funktioniert | Beweist, dass GRUB auf diese Festplatte schreiben kann, sodass ein einmaliger Boot wirklich einmalig ist |
| 2 | Der Prozess, einmal | -43, nur ein einziges Mal | Liest den Fix aus dem Kernel-Speicher und prüft alles, was der Host zuvor hatte. Eine Panic kehrt von selbst zum bekannt funktionierenden Kernel zurück |
| 3 | Der Prozess, einmal | -43, über den Standard-GRUB | Beweist den Endzustand, mit wiederhergestelltem Standard-GRUB und allen anderen Kerneln entfernt |
Was es garantiert:
complete bedeutet bewiesen. Dieser Status wird erst nach einem Boot über den finalen GRUB- und Kernel-Zustand erreicht, und der finale Datensatz erreicht Git, bevor der Status gespeichert wird.lock.json gibt an, was zu installieren ist, und enthält nichts über irgendeine Maschine. Der Fallback, die Entfernungslisten und die Health-Baseline werden alle vom Host gelesen und vor der ersten Änderung veröffentlicht.PROCEDURE.md nennt. Der nächste Boot setzt fort oder stoppt explizit.kernel-upgrade/vm/final-run.sh baut UEFI-Testmaschinen von Grund auf, mit einer emulierten 4-TB-NVMe-Festplatte, und führt das exakte Installationsprogramm darin aus. test-report.json zeichnet die Hashes dessen auf, was bestanden wurde, und install.sh weigert sich zu laufen, wenn der Code von diesem Bericht abweicht.
Die 24 Szenarien decken echte Stromausfälle während der Pakete, während der finalen Bereinigung und nach dem finalen Datensatz ab, Kernel-Panics und Hänger, GitHub-Ausfälle in jeder Phase sowie eine Maschine, die abgelehnt werden muss. from-zero baut eine Maschine mit dem echten Skript von personal_server aus dem echten Ubuntu-Archiv, sieht das Gate sie ablehnen, aktualisiert sie und sieht das Gate bestehen. from-zero benötigt einen Klon von personal_server neben diesem Repository.
Was VMs nicht zeigen können, ist in PROCEDURE.md aufgeführt. Das Wichtigste ist echte Firmware, die Boot 1 auf der Maschine selbst testet.
Dies lief am 2026-11-02 auf einem internetzugewandten Server mit einer 4-TB-NVMe-Festplatte und einer RTX 5090. Diese Maschine hat keine Remote-Konsole, nur einen Power-Switch im Netzwerk. Der erste Boot über den Standard-GRUB bestand jede Prüfung, mit 7.0.0-43 als einzigem Kernel und dem Fix, der im Live-Kernel-Speicher bestätigt wurde.
Die erste Version dieses Prozesses funktionierte dort, war aber nicht richtig. systemd beendete sie in ihren letzten Millisekunden, weil sie ihre eigene Unit-Datei während der Ausführung löschte. Sie bezeichnete sich außerdem als complete, bevor der Standard-GRUB gebootet hatte, und sie hatte die Details dieser Maschine fest eingebaut. Dieses Repository ist der Neuaufbau. Unabhängige Reviews fanden dann weitere echte Defekte, bevor es erneut lief, darunter eine Prüfung, die jeden echten NVMe-Host gestoppt hätte, nachdem sich seine Pakete geändert hatten.
├── 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
Der Code ist unter der Unlicense veröffentlicht. Die Pakete behalten ihre eigenen Lizenzen. Das Release enthält Canonicals Kernel-Pakete und dkms, da das Staging-Archiv alte Builds löscht. NVIDIAs Pakete werden hier nicht weiterverbreitet: Sie stammen aus Ihrem eigenen Ubuntu-Archiv.