Zapscape i SCTPhantom: el teu Proxmox no porta el kernel de Debian

Aquesta setmana s'han publicat dues fallades del kernel Linux amb nom propi. Zapscape permet sortir d'una màquina virtual KVM i quedar-se amb l'amfitrió. SCTPhantom converteix un usuari sense privilegis en root i s'endú la frontera del contenidor. Entendre-les costa vint minuts. La pregunta que de debò ens va ocupar el matí va ser una altra: el kernel que arrenca els nostres nodes ja les porta corregides? I aquesta pregunta no la respon cap de les dues fitxes.

Escrivim això des del costat de qui ho ha d'aplicar. Operem Proxmox VE amb emmagatzematge Ceph en producció, repartit en diversos datacenters, així que l'avís no era una lectura: era una llista de nodes que tocava reiniciar. I en anar a comprovar el que és obvi ens vam trobar amb el buit de què tracta aquest article, que no és tècnic sinó de procediment, i que es repeteix en moltíssims llocs més enllà de Proxmox.

Zapscape: sortir de la màquina virtual

CVE-2026-64561 és un ús després d'alliberar en l'emulació del shadow MMU de KVM en x86, concretament a la ruta recursiva de zap que s'executa quan KVM recicla pàgines d'ombra. El missatge del pedaç ho explica sense adorns: cal comprovar si l'arrel és invàlida o obsoleta després de deixar disponibles pàgines de MMU, no abans, perquè «si en reciclar pàgines d'ombra es destrueix una arrel en ús, KVM intentarà mapar memòria en una arrel invàlida», i les pàgines filles hereten el rol del pare, de manera que es creen invàlides i acaben a la llista de pàgines actives, que és justament el que KVM prometia que no passaria mai. L'arranjament és moure la comprovació darrere de make_mmu_pages_available().

El que cal per arribar-hi importa molt, i convé dir-ho abans que l'impacte: privilegi de kernel dins del convidat L1 —a la pràctica, root a la màquina virtual— i virtualització imbricada, perquè és el que força KVM a fer servir el shadow MMU en comptes de la paginació assistida per maquinari. A Intel cal, a més, que a aquest convidat se li hagin exposat els recorreguts de pàgina EPT de quatre i de cinc nivells; a AMD no hi ha condició equivalent. L'investigador Hyunwoo Kim, a qui s'acredita la troballa, va publicar una prova de concepte funcional contra AMD que demostra la cadena completa sobre QEMU en mode TCG amb tres capes apilades (L0, L1 i L2). Red Hat li ha posat de moment un 7,0 preliminar.

Hi ha un segon camí que es menciona menys i que en alguns servidors és el que de debò cou: on /dev/kvm és accessible per a usuaris normals, no cal ser llogater de ningú. Qualsevol amb un compte pot crear una màquina virtual d'un sol ús i atacar l'amfitrió des de dins. La fallada viu al KVM del kernel, de manera que la versió de QEMU que facis servir és indiferent.

SCTPhantom: divuit anys esperant

CVE-2026-64564 és a la reconfiguració dinàmica d'adreces de SCTP, el mecanisme ASCONF que permet a una associació afegir, treure o recol·locar rutes de xarxa sobre la marxa. El kernel valida l'esborrat d'una adreça fent servir l'adreça d'origen del paquet, però manté a banda un punter en memòria cau que apunta al transport triat pel paràmetre d'adreça del mateix missatge. Aquestes dues identitats no han de coincidir per força. Un sol ASCONF que porti, en ordre, [paràmetre L] [DEL-IP L] [DEL-IP 0.0.0.0] supera la comprovació existent, allibera el transport al qual continua apuntant el punter en memòria cau i després el reutilitza: l'associació acaba amb zero transports i amb la ruta primària apuntant a memòria alliberada.

El signa el Zhuque Lab de Tencent, que li assigna un 8,5 en CVSS 4.0 amb vector local (AV:L/PR:L) i diu haver aconseguit root als kernels que va provar de Debian 13, Ubuntu 24.04, OpenCloudOS i Rocky Linux 9 i RHEL 9 —aquests dos últims, amb el mòdul SCTP carregat a mà—. La part que més ens va interessar és l'escapada de contenidor: la cadena arriba a execució als espais de noms inicials sense necessitar CAP_NET_ADMIN ni CAP_SYS_ADMIN, amb sis encerts de vuit intents. I el codi defectuós es remunta a Linux 2.6.25, desembre del 2007. Divuit anys.

L'antiguitat impressiona i convé desinflar-la una mica, perquè no mesura risc. Al mateix pedaç de Zapscape hi ha una nota que ho explica millor que nosaltres: el defecte de fons existia des que KVM va començar a portar el compte d'arrels invàlides el 2008, però «la veritable maldat» només va aparèixer el 2020, amb Linux 5.9, quan es va afegir la garantia que ara es trenca. Dit d'una altra manera: una fallada pot portar anys al codi sense ser explotable, i tornar-se explotable el dia que algú introdueix, amb tota la bona intenció, una optimització al seu voltant. Que hi fos des de fa divuit anys no vol dir que ningú l'hagi estat explotant durant divuit anys.

La pregunta incòmoda: tinc el pedaç aplicat?

Les versions corregides que circulen a totes les cobertures són aquestes: 6.6.148, 6.12.101, 6.18.42, 7.1.6 i la 7.2-rc5 de desenvolupament. Ara executa uname -r en un node Proxmox VE. Respondrà una cosa semblant a 6.8.12-x-pve, 6.14.11-x-pve, 6.17.13-x-pve o 7.0.14-x-pve. Cap d'aquestes branques no surt a la llista. Ni per bé ni per mal: simplement no són les mateixes branques.

Debian va publicar l'avís DSA-6415-1, que tanca totes dues fallades a trixie amb el paquet linux en versió 6.12.101-1. Perfecte, tret d'un detall: aquest no és el kernel que arrenca el teu node. Proxmox VE és Debian, però el seu kernel no ve de Debian, ve d'Ubuntu. Ho diu la seva pròpia documentació: Proxmox VE 9.0 es va basar en el 6.14 derivat d'Ubuntu 25.04, Proxmox VE 9.1 va passar al 6.17 derivat d'Ubuntu 25.10 i Proxmox VE 9.2, publicat el 21 de maig del 2026, va estrenar el kernel 7.0 com a nou estàndard, també derivat d'Ubuntu. Pots tenir el paquet linux de Debian perfectament actualitzat a la màquina i no arrencar-lo mai.

Val per a qualsevol sistema amb kernel de fabricant —una cabina d'emmagatzematge, un NAS—: la fitxa del CVE i l'avís de la teva distribució et diuen que la fallada existeix, no si el binari que tu arrenques la porta corregida.

La resposta, amb xifres: amb el -9 no n'hi ha prou

La resposta és al repositori de pve-kernel, no a cap butlletí. A la branca 7.0, que és la que porta Proxmox VE 9.2, l'historial és explícit:

• 7.0.14-9 — «cherry-pick fix for CVE-2026-64561». Aquí entra Zapscape, juntament amb els arranjaments de CVE-2026-64562 i CVE-2026-64047 i d'altres que el mateix commit agrupa com a «further CVEs».
• 7.0.14-10 — «backport sctp: don't free the ASCONF's own transport…». Aquest és SCTPhantom, i entra al bump següent.
• 7.0.14-11 — un backport addicional d'x86/bugs («Make Safe-RET robust against interrupts»). És l'última publicada mentre escrivim això: si has de reiniciar, reinicia a aquesta.

D'aquí surt la dada pràctica de tot l'article: si et vas quedar al 7.0.14-9 tens Zapscape corregit i SCTPhantom no. Dues fallades amb nom, dos bumps consecutius, i una diferència d'un dígit que no apareix en cap notícia. Qui va reiniciar així que va veure el primer s'ha guanyat un segon reinici; qui va esperar un dia es va estalviar una finestra. També convé mirar de quin repositori menges: el -9 va aparèixer primer a pve-test i només l'endemà a pve-no-subscription, i la de subscripció acostuma a anar al darrere.

I si no ets a la 7.0? Aquí és on aquest article s'hauria quedat a mitges, perquè el mateix git respon per les altres branques. A Proxmox VE 8.x, el personal de Proxmox indica al seu fòrum que Zapscape queda cobert a proxmox-kernel-6.8.12-40-pve, i compte, perquè allà es repeteix el patró exacte: el backport d'SCTP entra al bump següent, 6.8.12-41, juntament amb el mateix arranjament d'x86/bugs. Amb el -40 tens Zapscape; SCTPhantom comença al -41. I a les branques 6.17 (Proxmox VE 9.1) i 6.14 (Proxmox VE 9.0) el git és eloqüent per omissió: no registren cap commit relacionat amb aquestes dues fallades, i el seu darrer moviment és del 20 de juliol i del 15 de maig respectivament. Si hi ets, encara no el tens.

Com es comprova al teu node

Quatre ordres. Les dues primeres diuen el que corre; les dues últimes, el que tens instal·lat:

uname -r                              # el que corre ARA, en memòria
pveversion -v | grep -i kernel        # versió de Proxmox i kernel actiu
apt list --installed 'proxmox-kernel-*'   # el que està INSTAL·LAT al disc
proxmox-boot-tool kernel list         # kernels sincronitzats a l'ESP (si fas servir proxmox-boot-tool)

La quarta només s'aplica si l'arrencada la gestiona proxmox-boot-tool —instal·lacions sobre ZFS o amb systemd-boot—; en una instal·lació amb GRUB clàssic no et servirà. I llista els kernels que se sincronitzen a l'ESP, no quin guanyarà l'arrencada: això es fixa amb proxmox-boot-tool kernel pin.

Un kernel instal·lat no és un kernel arrencat. Vam escriure fa uns dies sobre el ritme de pedaços de Chrome i el buit entre descarregar l'actualització i reiniciar el navegador; aquí és el mateix però sense marge d'interpretació, perquè un kernel només entra reiniciant. No hi ha pedaç en calent que valgui en un desplegament Proxmox estàndard.

En un clúster, el reinici és la feina de debò. El nostre ordre és sempre el mateix: migrar en viu les càrregues del node, buidar-lo, i només llavors reiniciar. Si hi ha Ceph a sota, posar noout abans de tocar res evita que el clúster comenci a reequilibrar terabytes perquè un node fa quatre minuts que és fora. I després de l'arrencada, comprovar que uname -r diu el que esperaves abans de passar al node següent. La resta del criteri amb què deixem un clúster a punt és al checklist de hardening que publiquem.

Qui ha de córrer i qui no

Aquí és on ens separem del to de les cobertures. Zapscape necessita que algú tingui privilegi de kernel dins d'un convidat i que aquest convidat tingui virtualització imbricada disponible. Si totes les màquines virtuals del teu clúster són teves o del teu client, si ningú de fora no hi té root i si no exposes imbricació, això és una finestra de manteniment ordinària, no una emergència de dissabte. Dir-ho al revés ven més articles, però desgasta la credibilitat de qui després avisa d'alguna cosa urgent de debò.

Ara, si vens allotjament VPS, si lliures màquines virtuals a tercers amb root a dins, si mantens imbricació encesa per a laboratoris o formació, o si /dev/kvm està obert a usuaris normals en una màquina compartida: llavors sí, això s'ha d'actualitzar ja. La diferència entre els dos escenaris no és la fallada, és qui té root dins dels teus convidats, que és una pregunta de disseny i no de seguretat reactiva.

SCTPhantom té un fre semblant i menys conegut: cal que SCTP sigui accessible. A la llista oss-security, Solar Designer va matisar que a la família RHEL el mòdul es distribueix dins del paquet kernel-modules-extra amb blacklist sctp i blacklist sctp_diag, de manera que l'administrador l'ha d'instal·lar i carregar expressament per quedar exposat. A Debian i Ubuntu, en canvi, Tencent va obtenir root a les instal·lacions que va provar. La comprovació costa un segon: lsmod | grep sctp.

Fronteres de gestió, no murs

El que ens sembla més interessant del parell no és cap de les dues fallades per separat, sinó el que diuen juntes. Una trenca la màquina virtual, l'altra trenca el contenidor, i totes dues apareixen la mateixa setmana al mateix kernel. Són les dues fronteres sobre les quals ho recolzem gairebé tot, i totes dues són, al capdavall, codi C que algú va escriure fa anys.

La conclusió que en traiem no és deixar de confiar en la virtualització —seria absurd, l'operem cada dia— sinó tractar-la com el que és: una frontera de gestió excel·lent i una frontera de seguretat raonable però no absoluta. Això canvia decisions concretes: no barrejar al mateix amfitrió càrregues amb nivells de confiança molt diferents, no deixar la imbricació encesa «per si de cas», i no tractar «és a una altra VM» com a equivalent a «és a una altra màquina». La mateixa lògica que apliquem en decidir quan un clúster s'ha de partir en dos: el que separa de debò és la frontera que has triat, no la que dones per suposada.

El que no faríem

• Reiniciar el clúster sencer alhora. Node a node, migrant i comprovant. Una fallada local que exigeix ser a dins no justifica quedar-se sense quòrum a mitja tarda.
• Donar per corregit el node perquè ha sortit l'avís de la distribució. És l'error concret que motiva aquest article. Comprova la versió del kernel que arrenques, no la del paquet que existeix.
• Bloquejar SCTP a cegues. Per a la majoria de servidors és una neteja assenyada, però si operes senyalització de telecomunicacions el protocol s'utilitza de debò. Mira lsmod abans d'escriure un blacklist.
• Tractar «no s'està explotant» com un permís indefinit. Hi ha prova de concepte pública per a Zapscape. El seu autor avisa que no és un exploit llest per fer servir —cal portar les accions d'L1 a un mòdul del kernel convidat i adaptar-lo al kconfig de l'amfitrió—, però afegeix a la mateixa frase que no és una tasca difícil. Això escurça el termini encara que avui no hi hagi campanyes.

La part avorrida d'això és la que realment decideix el resultat: saber quin kernel arrenca cada màquina, tenir una finestra en què reiniciar sense demanar permís a ningú i que algú miri l'historial del fabricant quan el butlletí genèric no hi arriba. És exactament la feina del manteniment d'un parc gestionat, i no es nota fins a la setmana en què calen dos reinicis seguits per un dígit de diferència. Si vols que revisem com està la teva virtualització, escriu-nos.