Atualização segura do kernel para CVE-2026-98432 no Ubuntu 24.04 com NVIDIA, e uma análise da falha
Isto move uma máquina Ubuntu 24.04 com uma GPU NVIDIA para um kernel que corrige a CVE-2026-98432, um use-after-free no código IPv4 TCP do kernel. Foi criado para uma máquina que você talvez não consiga acessar se a atualização der errado: nada é confiável até que tenha inicializado, e uma etapa que falha para explicitamente em vez de deixar um host quebrado.
Prefira as atualizações normais do Ubuntu se elas incluírem a correção. Isto existe porque, na emergência para a qual foi escrito, o único kernel corrigido era uma compilação de pré-lançamento no arquivo de staging da Canonical. O kernel publicado mais recente, 7.0.0-42, ainda tinha o bug.
Não se guie pelo número da versão. Leia o próprio código do kernel em execução com o gate do personal_server:
sudo bash scripts/14_verify_kernel_fixes.sh
Ele lê o código de máquina do kernel em execução a partir da memória ativa, e do kernel que o GRUB inicializa em seguida a partir de sua imagem. No kernel corrigido, inet_sock_destruct e tcp_v4_reqsk_destructor chamam kvfree_call_rcu. No vulnerável, eles chamam kfree.
Se falhar, tente primeiro a rota normal:
sudo apt-get update
sudo apt-get install --only-upgrade linux-generic-hwe-24.04
sudo systemctl reboot
Use este repositório apenas se isso não trouxer um kernel fixo.
Você precisa da sua própria cópia, porque o processo publica seu registro de auditoria no Git enquanto é executado. Faça um fork deste repositório e, na máquina:
git clone <your fork> && cd <it>
kernel-upgrade/install.sh
sudo systemctl reboot
Aguarde cerca de 8 minutos para as reinicializações. A máquina reinicia sozinha mais duas vezes e não precisa de nada de você:
uname -r # must print 7.0.0-43-generic
python3 -I kernel-upgrade/upgrade.py status # must say complete
Se a máquina não for compatível, o instalador explica o motivo e não altera nada. kernel-upgrade/PROCEDURE.md descreve o que o host precisa, todas as falhas e o que fazer em cada caso, além do limite de falha.
| Boot | Quem o inicia | Kernel | O que acontece |
|---|---|---|---|
| 1 | Você | Um kernel sabidamente funcional aqui | Comprova que o GRUB consegue gravar neste disco, então um boot único realmente é único |
| 2 | O processo, uma vez | -43, apenas uma vez | Lê a correção da memória do kernel e verifica tudo o que o host tinha antes. Um panic retorna sozinho ao kernel sabidamente bom |
| 3 | O processo, uma vez | -43, pelo GRUB padrão | Comprova o estado final, com o GRUB padrão restaurado e todos os outros kernels removidos |
O que ele garante:
complete significa comprovado. Esse status só é atingido após um boot pelo estado final do GRUB e do kernel, e o registro final chega ao Git antes de o status ser salvo.lock.json diz o que instalar e não contém nada sobre nenhuma máquina. O fallback, as listas de remoção e a linha de base de saúde são todos lidos do host e publicados antes da primeira alteração.PROCEDURE.md nomeia. O próximo boot continua ou para explicitamente.kernel-upgrade/vm/final-run.sh cria máquinas de teste UEFI do zero, com um disco NVMe emulado de 4 TB, e executa o instalador exato nelas. test-report.json registra os hashes do que passou, e install.sh se recusa a executar se o código diferir desse relatório.
Os 24 cenários cobrem quedas de energia reais durante os pacotes, durante a purga final e após o registro final, kernel panics e travamentos, indisponibilidade do GitHub em cada etapa, e uma máquina que deve ser recusada. from-zero cria uma máquina com o script real do personal_server a partir do arquivo real do Ubuntu, vê o gate recusá-la, faz o upgrade e vê o gate aprová-la. from-zero precisa de um clone do personal_server ao lado deste repositório.
O que as VMs não conseguem mostrar está listado em PROCEDURE.md. O principal é o firmware real, que o boot 1 testa na própria máquina.
Isto foi executado em um servidor exposto à internet com um disco NVMe de 4 TB e uma RTX 5090 em 2026-11-02. Essa máquina não tem console remoto, apenas um interruptor de energia na rede. O primeiro boot pelo GRUB padrão passou em todas as verificações, com 7.0.0-43 como seu único kernel e a correção confirmada na memória do kernel em execução.
A primeira versão deste processo funcionou ali, mas não estava correta. O systemd a encerrou nos últimos milissegundos, porque ela apagou seu próprio arquivo de unit enquanto executava. Ela também se declarava complete antes de o GRUB padrão ter dado boot, e tinha os detalhes dessa máquina embutidos no código. Este repositório é a reconstrução. Revisões independentes então encontraram outros defeitos reais antes de ela rodar novamente, incluindo uma verificação que teria parado todo host NVMe real após seus pacotes terem sido alterados.
├── 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
O código é distribuído sob a Unlicense. Os pacotes mantêm suas próprias licenças. A release contém os pacotes de kernel da Canonical e o dkms, porque o arquivo de staging exclui builds antigos. Os pacotes da NVIDIA não são redistribuídos aqui: eles vêm do seu próprio repositório Ubuntu.