Set versions corregides al CVE i cap no arrenca el teu Proxmox

L'avís de CVE-2026-98432 porta una llista neta de versions corregides: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 i 7.2.10. Set. Si administres Proxmox, obre una consola i escriu uname -r: el número que surt no s'assembla a cap d'aquests set. No perquè vagis endarrerit, sinó perquè la branca que arrenca el teu node no existeix com a branca estable a kernel.org. Aquesta distància —entre la llista de l'avís i la cadena que imprimeix el teu servidor— és el forat per on es colen els pedaços que tothom dóna per posats.

Què es trenca: una opció de capçalera del 1981 i una cursa entre dues CPU

El títol del pedaç ho diu tot en una línia: «ipv4: free inet_opt and ireq_opt after an RCU grace period». Quan arriba un SYN, el kernel desa les opcions IP d'aquell paquet al request socket. En completar-se la salutació, tcp_v4_syn_recv_sock() traspassa la propietat d'aquell bloc al socket fill en lloc de copiar-lo. Si mentrestant una altra CPU processa un SYN retransmès del mateix client i fabrica un SYNACK, acaba llegint un bloc que ja s'ha alliberat amb un kfree() pelat. Ús després d'alliberar, al camí de xarxa, abans que cap aplicació hagi autenticat ningú.

Dins d'aquest mateix registre, l'equip del kernel justifica la nota de 9,8 camp a camp. Per al vector de xarxa escriu, literalment: «An unauthenticated peer supplies IPv4 Record Route or Timestamp bytes in a TCP SYN». És a dir: la fallada no la dispara qualsevol connexió TCP. La dispara una connexió el SYN de la qual porta opcions de capçalera IP —Record Route o Timestamp, dos camps que vénen de l'RFC 791, del 1981— i que a més es retransmet a temps per guanyar la cursa.

Aquest detall canvia la feina de dilluns al matí. Abans d'arribar-hi, dos matisos del mateix text que convé no perdre. El primer: hi ha una segona cursa, diferent, a la migració de request sockets, i només apareix si tens net.ipv4.tcp_migrate_req=1 o un programa BPF_SK_REUSEPORT_SELECT_OR_MIGRATE carregat. El segon: IPv6 no està afectat per la primera, perquè tcp_v6_syn_recv_sock() sí que duplica les opcions. L'arranjament, quan arriba, són dos kfree_rcu() a inet_sock_destruct() i tcp_v4_reqsk_destructor(). Dues línies, una a cada fitxer: el diff del commit és 2 files changed, 2 insertions(+), 2 deletions(-). El problema mai no va ser escriure-les.

Les set versions, i per què cap no és la teva

El registre del CVE marca com a afectat tot des de la 4.4 —gener del 2016— i dona per corregides aquestes branques: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 i 7.2.10. Mira què tenen en comú: 5.10, 5.15, 6.1, 6.6, 6.12 i 6.18 són les sis longterm vives, i 7.2 continua rebent estables al costat de la 7.3, que és l'actual. L'arranjament va entrar a la 7.3 directament, a la 7.3-rc7, i per això el CVE la llista a part. Són les branques que kernel.org manté avui, i res més.

Ara mira l'altra llista. Segons la wiki oficial de Proxmox, Proxmox VE 8.2 i posteriors arrenquen per defecte un kernel 6.8 derivat d'Ubuntu 24.04; des de 8.4 hi ha un 6.14 opcional, derivat d'Ubuntu 25.04; Proxmox VE 9.0 portava aquest mateix 6.14 i des de 9.1 el defecte va passar al 6.17, derivat d'Ubuntu 25.10. Aquesta wiki, a més, es va quedar a la 9.1. El roadmap oficial diu que Proxmox VE 9.2, publicada el 21 de maig del 2026, porta «Latest 7.0 Kernel as new stable default»: la sèrie 7.0, que és justament la que el projecte està apedaçant aquests dies. Cap d'aquestes quatre branques —6.8, 6.14, 6.17, 7.0— figura entre les set de l'avís. Cap no figura tampoc entre les que manté kernel.org. Són branques que ja han mort aigües amunt i que sobreviuen perquè Ubuntu les sosté i Proxmox construeix a sobre. Ja vam explicar aquesta mateixa mecànica quan van sortir Zapscape i SCTPhantom: el teu Proxmox no porta el kernel de Debian, i per això les versions de l'avís no existeixen al teu servidor.

La conseqüència pràctica és incòmoda: la llista de versions corregides d'un CVE del kernel no és una resposta, és un canvi de pregunta. No et diu si estàs fora de perill. Et diu a quin proveïdor has d'anar a preguntar. I cada proveïdor va al seu ritme.

El rellotge de cada distribució, a 31 d'octubre

El rastrejador de seguretat d'Ubuntu data la publicació el 15 d'octubre del 2026. Això és el que hi havia setze dies després, el 31 al matí, consultats un per un:

Les dues últimes files es creuen. Al mateix fil, un participant va reconstruir la cadena de commits: l'arranjament «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». I aquesta font 7.0.0-43 és la mateixa que el rastrejador d'Ubuntu continua donant per no alliberada per a la seva pròpia 26.04 LTS: el tag concret que va empaquetar Proxmox és Ubuntu-7.0.0-43.43i1. O sigui: Proxmox ja ha empaquetat, signat i publicat —fins i tot al repositori d'empresa— un kernel construït a partir d'una font que Ubuntu encara no ha lliurat als seus usuaris. Ningú no ha fet res malament; és que són dos calendaris de publicació diferents sobre el mateix codi. Però si el teu procediment de pedaços és «miro el butlletí de la distribució», avui aquesta frase significa coses oposades segons en quin node estiguis.

Què prova l'exploit ja publicat (i què no)

El 27 d'octubre, Anthropic va publicar que un model intern no alliberat havia construït cinc cadenes d'explotació funcionals, una contra aquesta fallada. D'aquí va sortir el titular de root remot sense credencials a Linux. És cert i està incomplet, i la part que falta importa: el seu propi text acota l'objectiu a «Linux servers with a multipath TCP listener», és a dir, servidors amb un escoltador MPTCP. El text del CVE, en canvi, no esmenta MPTCP ni una sola vegada: anomena les funcions de la salutació IPv4 corrent. La cadena va trigar uns 48 minuts a filtrar un punter del kernel i trencar KASLR, i cinc més a arribar a executar ordres com a root.

Hi ha un detall d'aquest mateix informe que convé no perdre, perquè explica per què una cursa difícil no és una cursa improbable: «a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed». Un intent fallit no deixa soroll ni tomba el servidor; es reintenta i prou. Les dues lectures conviuen i cap no guanya de moment. Si tries la tranquil·litzadora —«no tinc MPTCP, no m'afecta»— estàs apostant que una demostració concreta marca el límit del que és explotable, i això gairebé mai no ha estat cert al kernel. Si tries l'alarmista —«root remot a qualsevol Linux»— estàs afirmant una cosa que ningú no ha ensenyat encara. Nosaltres ens quedem amb la tercera, que és l'avorrida: el 9,8 el posa l'equip del kernel per la mena de corrupció que permet, no pel nombre de cadenes publicades, i aquesta nota ja basta per tractar-ho com a urgent sense necessitat d'adornar-ho.

Sis comprovacions, amb ordre

Això és el que faríem avui en un parc mixt, en aquest ordre. No triga ni mitja hora.

Quan aquesta regla no et serveix

La regla del punt 6 és el millor que hi ha disponible mentre el teu proveïdor empaqueta, i tot i així cal dir en veu alta les tres coses que no fa. No tanca la segona cursa: la de migració de request sockets no depèn que el SYN porti opcions, depèn del sysctl del punt 3. No està on et penses si el trànsit va a màquines virtuals per un pont: un hook d'input veu el que entra a l'amfitrió, no el que creua el bridge; si vols cobrir això, la regla va on els paquets passen de debò. I no és el pedaç: el teu escàner de compliment continuarà traient el CVE en vermell, amb raó.

Hi ha un cas, a més, en què ni l'aplicaríem: si la teva única exposició IPv4 entrant ja passa per un equip aigües amunt que descarta les opcions de capçalera —cosa que fa part de l'equipament de vora—, estàs afegint una regla que no comptarà ni un sol paquet. No és gratis: és una taula més que algú haurà de recordar-se d'esborrar d'aquí a tres setmanes. Posa el comptador, mira'l a les 24 hores i decideix amb el número al davant.

Què deixa això sobre la taula

Setze dies després de publicar-se un 9,8 preautenticació, la resposta a «estem apedaçats?» no estava a l'avís, ni a una web, ni a un número de versió: estava repartida entre quatre rastrejadors que deien coses diferents i en una cadena —la d'uname -r— que cal anar a buscar node per node. Això és un problema d'inventari abans que del kernel, i s'arregla abans del pròxim CVE o no s'arregla.

La segona cosa és encara menys còmoda: el reinici. L'arranjament és un kernel nou, i un kernel nou és una finestra. Ja vam escriure sobre el que costa de debò un reinici planificat i sobre el que costa no tenir-lo planificat; aquí es nota igual. Un clúster Proxmox amb migració en viu et deixa fer-ho node a node sense apagar res, i això no és una virtut del programari, és una decisió d'arquitectura que es pren molt abans del dia del pedaç. És la part d'infraestructura i cloud que no llueix en cap presentació i que decideix si el dimarts de pedaços és rutina o és nit.

Nosaltres operem Proxmox VE amb Ceph en producció, repartit en diversos datacenters, així que aquests matins també són nostres. Si vols que els porti algú: a ciberseguretat gestionada traduïm cada avís a la versió que arrenca el teu node, i a manteniment informàtic hi va la finestra, l'ordre de reinici i la prova que va quedar posat. No som resellers de Proxmox ni de Red Hat: no venem llicències de cap de les dues, així que si la conclusió és que ja estàs cobert, t'ho direm i s'ha acabat. escriu-nos i ho mirem.

Fonts (consultades el 31 d'octubre del 2026): el títol del pedaç, la descripció tècnica, el rang afectat des de la 4.4, les set versions corregides, la segona cursa amb net.ipv4.tcp_migrate_req, l'exempció d'IPv6 i la frase «An unauthenticated peer supplies IPv4 Record Route or Timestamp bytes in a TCP SYN» surten del registre oficial de CVE-2026-98432 publicat per l'equip del kernel, que inclou la puntuació CVSS 3.1 de 9,8 i la seva justificació camp a camp. Les branques vives de kernel.org són de releases.json. Els estats per versió d'Ubuntu i la data de publicació del 15-10-2026 són del rastrejador de seguretat d'Ubuntu; els de Debian, del rastrejador de Debian. La citació de Red Hat i la regla nftables amb prioritat −310 són del seu butlletí RHSB-2026-016 i de la seva fitxa del CVE. Les versions 7.0.14-25-pve i -26, la citació de l'equip sobre els repositoris d'empresa i l'explicació sobre la font Ubuntu 7.0.0-43 són del fil oficial del fòrum de Proxmox. La correspondència entre versions de Proxmox VE i branques de kernel és de la wiki Proxmox VE Kernel. Que Proxmox VE 9.2 (21-05-2026) porta «Latest 7.0 Kernel as new stable default» surt del roadmap de Proxmox VE, perquè aquella wiki es va quedar a la 9.1. El diff de dues línies és del e3f33b0a1d89 a l'arbre d'en Linus. L'objectiu de l'exploit, les fases i els temps (48 minuts fins al punter del kernel, cinc més fins a la shell) són de Discovering vulnerabilities with Claude, publicat el 27-10-2026 i enllaçat des de les mateixes referències del butlletí de Red Hat. L'observació que Ubuntu continua en work in progress encara que el codi ja hi sigui és del fil del fòrum, no nostra. El que és nostre és la lectura que una llista de versions corregides és un canvi de pregunta i no una resposta, l'ordre de les sis comprovacions i els tres límits de la regla nftables. Foto de portada: Cable closet bh.jpg, domini públic, via Wikimedia Commons.