Actualización segura del kernel para CVE-2026-98432 en Ubuntu 24.04 con NVIDIA, y un análisis del fallo
Esto migra una máquina Ubuntu 24.04 con una GPU NVIDIA a un kernel que corrige CVE-2026-98432, un use-after-free en el código IPv4 TCP del kernel. Está diseñado para una máquina a la que quizá no puedas acceder si la actualización sale mal: no se confía en nada hasta que haya arrancado, y un paso fallido se detiene de forma explícita en lugar de dejar un host roto.
Prefiere las actualizaciones normales de Ubuntu si incluyen la corrección. Esto existe porque, en la emergencia para la que fue escrito, el único kernel corregido era una compilación preliminar en el archivo de staging de Canonical. El kernel publicado más reciente, 7.0.0-42, seguía teniendo el fallo.
No te guíes por el número de versión. Lee el propio código del kernel en ejecución con la puerta de personal_server:
sudo bash scripts/14_verify_kernel_fixes.sh
Lee el código máquina del kernel en ejecución desde la memoria activa, y del kernel que GRUB arranca a continuación desde su imagen. En el kernel corregido, inet_sock_destruct y tcp_v4_reqsk_destructor llaman a kvfree_call_rcu. En el vulnerable llaman a kfree.
Si falla, prueba primero la ruta normal:
sudo apt-get update
sudo apt-get install --only-upgrade linux-generic-hwe-24.04
sudo systemctl reboot
Úsalo solo si eso no conlleva un kernel fijo.
Necesitas tu propia copia, porque el proceso publica su registro de auditoría en Git mientras se ejecuta. Haz un fork de este repositorio y, en la máquina:
git clone <your fork> && cd <it>
kernel-upgrade/install.sh
sudo systemctl reboot
Deja unos 8 minutos para los reinicios. La máquina se reinicia dos veces más y no necesita nada de tu parte:
uname -r # must print 7.0.0-43-generic
python3 -I kernel-upgrade/upgrade.py status # must say complete
Si la máquina no cumple los requisitos, el instalador explica por qué y no cambia nada. kernel-upgrade/PROCEDURE.md contiene lo que necesita el host, cada fallo y qué hacer al respecto, y el límite de fallo.
| Arranque | Quién lo inicia | Kernel | Qué ocurre |
|---|---|---|---|
| 1 | Tú | Un kernel que se sabe que funciona aquí | Demuestra que GRUB puede escribir en este disco, así que un arranque único realmente es único |
| 2 | El proceso, una vez | -43, solo una vez | Lee la corrección desde la memoria del kernel y comprueba todo lo que el host tenía antes. Un pánico regresa por sí solo al kernel que se sabe que funciona |
| 3 | El proceso, una vez | -43, a través del GRUB estándar | Demuestra el estado final, con el GRUB estándar restaurado y todos los demás kernels eliminados |
Lo que garantiza:
complete significa probado. Ese estado solo se alcanza tras un arranque a través del GRUB y el kernel del estado final, y el registro final llega a Git antes de que se guarde el estado.lock.json indica qué instalar y no contiene nada sobre ninguna máquina. El fallback, las listas de eliminación y la línea base de salud se leen del host, y se publican antes del primer cambio.PROCEDURE.md. El siguiente arranque continúa o se detiene de forma explícita.kernel-upgrade/vm/final-run.sh construye máquinas de prueba UEFI desde cero, con un disco NVMe emulado de 4 TB, y ejecuta el instalador exacto en ellas. test-report.json registra los hashes de lo que pasó, y install.sh se niega a ejecutarse si el código difiere de ese informe.
Los 24 escenarios cubren cortes de energía reales durante los paquetes, durante la purga final y después del registro final, pánicos y bloqueos del kernel, caídas de GitHub en cada etapa, y una máquina que debe ser rechazada. from-zero construye una máquina con el script real de personal_server desde el archivo real de Ubuntu, ve que la puerta la rechaza, la actualiza y ve que la puerta la acepta. from-zero necesita un clon de personal_server junto a este repositorio.
Lo que las VM no pueden mostrar se enumera en PROCEDURE.md. El principal es el firmware real, que el arranque 1 prueba en la propia máquina.
Esto se ejecutó en un servidor expuesto a internet con un disco NVMe de 4 TB y una RTX 5090 el 2026-11-02. Esa máquina no tiene consola remota, solo un interruptor de encendido en la red. El primer arranque a través del GRUB estándar pasó todas las comprobaciones, con 7.0.0-43 como su único kernel y la corrección confirmada en la memoria del kernel en vivo.
La primera versión de este proceso funcionó allí pero no era correcta. systemd la mató en sus últimos milisegundos, porque eliminó su propio archivo de unidad mientras se ejecutaba. También se declaró complete antes de que el GRUB estándar hubiera arrancado, y tenía los detalles de esa máquina integrados. Este repositorio es la reconstrucción. Revisiones independientes encontraron después más defectos reales antes de que se ejecutara de nuevo, incluida una comprobación que habría detenido a todos los hosts NVMe reales después de que sus paquetes hubieran cambiado.
├── 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
El código se publica bajo la Unlicense. Los paquetes conservan sus propias licencias. La release contiene los paquetes de kernel de Canonical y dkms, porque el archivo de staging elimina las compilaciones antiguas. Los paquetes de NVIDIA no se redistribuyen aquí: provienen de tu propio archivo de Ubuntu.