Siete versiones corregidas en el CVE y ninguna arranca tu Proxmox

El aviso de CVE-2026-98432 trae una lista limpia de versiones corregidas: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 y 7.2.10. Siete. Si administras Proxmox, abre una consola y escribe uname -r: el número que sale no se parece a ninguno de esos siete. No porque vayas atrasado, sino porque la rama que arranca tu nodo no existe como rama estable en kernel.org. Esa distancia —entre la lista del aviso y la cadena que imprime tu servidor— es el agujero por el que se cuelan los parches que todo el mundo da por puestos.

Qué se rompe: una opción de cabecera de 1981 y una carrera entre dos CPU

El título del parche lo dice todo en una línea: «ipv4: free inet_opt and ireq_opt after an RCU grace period». Cuando llega un SYN, el kernel guarda las opciones IP de ese paquete en el request socket. Al completarse el saludo, tcp_v4_syn_recv_sock() traspasa la propiedad de ese bloque al socket hijo en lugar de copiarlo. Si mientras tanto otra CPU procesa un SYN retransmitido del mismo cliente y fabrica un SYNACK, acaba leyendo un bloque que ya se liberó con un kfree() pelado. Uso después de liberar, en el camino de red, antes de que ninguna aplicación haya autenticado a nadie.

Dentro de ese mismo registro, el equipo del kernel justifica la nota de 9,8 campo a campo. Para el vector de red escribe, literalmente: «An unauthenticated peer supplies IPv4 Record Route or Timestamp bytes in a TCP SYN». Es decir: el fallo no lo dispara cualquier conexión TCP. Lo dispara una conexión cuyo SYN lleva opciones de cabecera IP —Record Route o Timestamp, dos campos que vienen del RFC 791, de 1981— y que además se retransmite a tiempo para ganar la carrera.

Ese detalle cambia el trabajo del lunes por la mañana. Antes de llegar ahí, dos matices del mismo texto que conviene no perder. El primero: hay una segunda carrera, distinta, en la migración de request sockets, y solo aparece si tienes net.ipv4.tcp_migrate_req=1 o un programa BPF_SK_REUSEPORT_SELECT_OR_MIGRATE cargado. El segundo: IPv6 no está afectado por la primera, porque tcp_v6_syn_recv_sock() sí duplica las opciones. El arreglo, cuando llega, son dos kfree_rcu() en inet_sock_destruct() y tcp_v4_reqsk_destructor(). Dos líneas, una en cada fichero: el diff del commit es 2 files changed, 2 insertions(+), 2 deletions(-). El problema nunca fue escribirlas.

Las siete versiones, y por qué ninguna es la tuya

El registro del CVE marca como afectado todo desde la 4.4 —enero de 2016— y da por corregidas estas ramas: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 y 7.2.10. Mira qué tienen en común: 5.10, 5.15, 6.1, 6.6, 6.12 y 6.18 son las seis longterm vivas, y 7.2 sigue recibiendo estables junto a la 7.3, que es la actual. El arreglo entró en la 7.3 directamente, en la 7.3-rc7, y por eso el CVE la lista aparte. Son las ramas que kernel.org mantiene hoy, y nada más.

Ahora mira la otra lista. Según la wiki oficial de Proxmox, Proxmox VE 8.2 y posteriores arrancan por defecto un kernel 6.8 derivado de Ubuntu 24.04; desde 8.4 hay un 6.14 opcional, derivado de Ubuntu 25.04; Proxmox VE 9.0 llevaba ese mismo 6.14 y desde 9.1 el defecto pasó al 6.17, derivado de Ubuntu 25.10. Esa wiki, además, se quedó en la 9.1. El roadmap oficial dice que Proxmox VE 9.2, publicada el 21 de mayo de 2026, trae «Latest 7.0 Kernel as new stable default»: la serie 7.0, que es justo la que el proyecto está parcheando estos días. Ninguna de esas cuatro ramas —6.8, 6.14, 6.17, 7.0— figura entre las siete del aviso. Ninguna figura tampoco entre las que mantiene kernel.org. Son ramas que ya murieron aguas arriba y que sobreviven porque Ubuntu las sostiene y Proxmox construye encima. Ya contamos esta misma mecánica cuando salieron Zapscape y SCTPhantom: tu Proxmox no lleva el kernel de Debian, y por eso las versiones del aviso no existen en tu servidor.

La consecuencia práctica es incómoda: la lista de versiones corregidas de un CVE del kernel no es una respuesta, es un cambio de pregunta. No te dice si estás a salvo. Te dice a qué proveedor tienes que ir a preguntar. Y cada proveedor va a su ritmo.

El reloj de cada distribución, a 31 de octubre

El rastreador de seguridad de Ubuntu fecha la publicación el 15 de octubre de 2026. Esto es lo que había dieciséis días después, el 31 por la mañana, consultados uno por uno:

Las dos últimas filas se cruzan. En el mismo hilo, un participante reconstruyó la cadena de commits: el arreglo «reached the Ubuntu 7.0.0-43 kernel source, and the Proxmox kernel is built on that source starting with 7.0.14-25-pve». Y esa fuente 7.0.0-43 es la misma que el rastreador de Ubuntu sigue dando por no liberada para su propia 26.04 LTS: el tag concreto que empaquetó Proxmox es Ubuntu-7.0.0-43.43i1. O sea: Proxmox ya ha empaquetado, firmado y publicado —hasta en el repositorio de empresa— un kernel construido a partir de una fuente que Ubuntu todavía no ha entregado a sus usuarios. Nadie ha hecho nada mal; es que son dos calendarios de publicación distintos sobre el mismo código. Pero si tu procedimiento de parcheo es «miro el boletín de la distribución», hoy esa frase significa cosas opuestas según en qué nodo estés.

Lo que el exploit ya publicado prueba (y lo que no)

El 27 de octubre, Anthropic publicó que un modelo interno no liberado había construido cinco cadenas de explotación funcionales, una de ellas contra este fallo. De ahí salió el titular de root remoto sin credenciales en Linux. Es cierto y está incompleto, y la parte que falta importa: su propio texto acota el objetivo a «Linux servers with a multipath TCP listener», es decir, servidores con un escuchador MPTCP. El texto del CVE, en cambio, no menciona MPTCP ni una sola vez: nombra las funciones del saludo IPv4 corriente. La cadena tardó unos 48 minutos en filtrar un puntero del kernel y romper KASLR, y cinco más en llegar a ejecutar órdenes como root.

Hay un detalle de ese mismo informe que conviene no perderse, porque explica por qué una carrera difícil no es una carrera improbable: «a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed». Un intento fallido no deja ruido ni tira el servidor; se reintenta y ya está. Las dos lecturas conviven y ninguna gana por ahora. Si eliges la tranquilizadora —«no tengo MPTCP, no me afecta»— estás apostando a que una demostración concreta marca el límite de lo explotable, y eso casi nunca ha sido verdad en el kernel. Si eliges la alarmista —«root remoto en cualquier Linux»— estás afirmando algo que nadie ha enseñado todavía. Nosotros nos quedamos con la tercera, que es la aburrida: el 9,8 lo pone el equipo del kernel por la clase de corrupción que permite, no por el número de cadenas publicadas, y esa nota ya basta para tratarlo como urgente sin necesidad de adornarlo.

Seis comprobaciones, con comando

Esto es lo que haríamos hoy en un parque mixto, en este orden. No lleva media hora.

Cuándo esa regla no te sirve

La regla del punto 6 es lo mejor que hay disponible mientras tu proveedor empaqueta, y aun así hay que decir en voz alta las tres cosas que no hace. No cierra la segunda carrera: la de migración de request sockets no depende de que el SYN lleve opciones, depende del sysctl del punto 3. No está donde crees si el tráfico va a máquinas virtuales por un puente: un hook de input ve lo que entra al anfitrión, no lo que cruza el bridge; si quieres cubrir eso, la regla va donde los paquetes pasan de verdad. Y no es el parche: tu escáner de cumplimiento va a seguir sacando el CVE en rojo, con razón.

Hay un caso, además, en el que ni la aplicaríamos: si tu única exposición IPv4 entrante ya pasa por un equipo aguas arriba que descarta las opciones de cabecera —cosa que hace parte del equipamiento de borde—, estás añadiendo una regla que no va a contar un solo paquete. No es gratis: es una tabla más que alguien tendrá que acordarse de borrar dentro de tres semanas. Pon el contador, míralo a las 24 horas y decide con el número delante.

Lo que esto deja sobre la mesa

Dieciséis días después de publicarse un 9,8 preautenticación, la respuesta a «¿estamos parcheados?» no estaba en el aviso, ni en una web, ni en un número de versión: estaba repartida en cuatro rastreadores que decían cosas distintas y en una cadena —la de uname -r— que hay que ir a buscar nodo por nodo. Eso es un problema de inventario antes que del kernel, y se arregla antes del siguiente CVE o no se arregla.

Lo segundo es menos cómodo todavía: el reinicio. El arreglo es un kernel nuevo, y un kernel nuevo es una ventana. Ya escribimos sobre lo que cuesta de verdad un reinicio planificado y sobre lo que cuesta no tenerlo planificado; aquí se nota igual. Un clúster Proxmox con migración en vivo te deja hacerlo nodo a nodo sin apagar nada, y eso no es una virtud del software, es una decisión de arquitectura que se toma mucho antes del día del parche. Es la parte de infraestructura y cloud que no luce en ninguna presentación y que decide si el martes de parches es rutina o es noche.

Nosotros operamos Proxmox VE con Ceph en producción, repartido en varios datacenters, así que estas mañanas también son nuestras. Si quieres que las lleve alguien: en ciberseguridad gestionada traducimos cada aviso a la versión que arranca tu nodo, y en mantenimiento informático va la ventana, el orden de reinicio y la prueba de que quedó puesto. No somos resellers de Proxmox ni de Red Hat: no vendemos licencias de ninguna, así que si la conclusión es que ya estás cubierto, te lo diremos y se acabó. escríbenos y lo miramos.

Fuentes (consultadas el 31 de octubre de 2026): el título del parche, la descripción técnica, el rango afectado desde la 4.4, las siete versiones corregidas, la segunda carrera con net.ipv4.tcp_migrate_req, la exención de IPv6 y la frase «An unauthenticated peer supplies IPv4 Record Route or Timestamp bytes in a TCP SYN» salen del registro oficial de CVE-2026-98432 publicado por el equipo del kernel, que incluye la puntuación CVSS 3.1 de 9,8 y su justificación campo a campo. Las ramas vivas de kernel.org son de releases.json. Los estados por versión de Ubuntu y la fecha de publicación del 15-10-2026 son del rastreador de seguridad de Ubuntu; los de Debian, del rastreador de Debian. La cita de Red Hat y la regla nftables con prioridad −310 son de su boletín RHSB-2026-016 y de su ficha del CVE. Las versiones 7.0.14-25-pve y -26, la cita del equipo sobre los repositorios de empresa y la explicación sobre la fuente Ubuntu 7.0.0-43 son del hilo oficial del foro de Proxmox. La correspondencia entre versiones de Proxmox VE y ramas de kernel es de la wiki Proxmox VE Kernel. Que Proxmox VE 9.2 (21-05-2026) trae «Latest 7.0 Kernel as new stable default» sale del roadmap de Proxmox VE, porque esa wiki se quedó en la 9.1. El diff de dos líneas es del e3f33b0a1d89 en el árbol de Linus. El objetivo del exploit, las fases y los tiempos (48 minutos hasta el puntero del kernel, cinco más hasta la shell) son de Discovering vulnerabilities with Claude, publicado el 27-10-2026 y enlazado desde las propias referencias del boletín de Red Hat. La observación de que Ubuntu sigue en work in progress aunque el código ya esté dentro es del hilo del foro, no nuestra. Lo nuestro es la lectura de que una lista de versiones corregidas es un cambio de pregunta y no una respuesta, el orden de las seis comprobaciones y los tres límites de la regla nftables. Foto de portada: Cable closet bh.jpg, dominio público, vía Wikimedia Commons.