El pedaç del nucli és un reinici, i el reinici esborra la prova

Avui, divendres, el catàleg de vulnerabilitats explotades de CISA ha crescut en dues línies. Totes dues diuen Linux, totes dues diuen Kernel i totes dues vencen dilluns. Una porta onze mesos al teu escàner amb un 3,3 sobre 10, en el color que ningú no mira.

El 3,3 és real i és a la fitxa oficial. El NVD va publicar CVE-2025-39964 el 13 d'octubre de 2025 amb el vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L: local, sense impacte en confidencialitat ni en integritat, i una disponibilitat «baixa». Dit clar: un usuari del sistema pot corrompre unes dades. Tres-cents quaranta dies després, CISA diu que algú l'està fent servir de debò.

A la mateixa pàgina hi ha una segona puntuació, la del CNA que va assignar el CVE —el mateix projecte del nucli—: 7,8, amb C:H/I:H/A:H. Quatre punts i mig de diferència sobre el mateix error, a la mateixa fitxa, sense que cap dels dos s'hagi equivocat.

Dos números per a tres preguntes

El NVD puntua el que el pedaç diu que arregla, i el missatge de l'arranjament és sec: «Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state.» Dades entremesclades: disponibilitat baixa, zero confidencialitat, zero integritat. El CNA del nucli puntua una altra cosa: què arriba a ser una condició de cursa que deixa inconsistent l'estat intern d'un socket quan algú s'hi asseu de debò.

Cap de les dues xifres respon a la tercera pregunta, que és l'única que estreny un divendres a la tarda: ho està fent servir algú? Aquesta la contesta el catàleg de CISA, i la contesta amb una data d'alta i un termini. Avui 18, venç el 21.

Opinió: si la teva cua de pedaços s'ordena per la puntuació que porta l'escàner, aquest error portava onze mesos a la pàgina quatre. No és culpa de l'escàner. És el que passa quan es demana a una sola xifra que contesti tres preguntes diferents —què trenca, fins on arriba i qui ho està fent servir— i només en sap contestar la primera.

L'altre viu al pont per on passen les teves màquines

CVE-2026-53266 es va publicar el 25 de juny i ha trigat 85 dies a entrar al catàleg. És una escriptura fora de rang (CWE-787) a l'objectiu SNAT d'ebtables, el tallafoc del pont Ethernet. El missatge del commit: la reescriptura de l'adreça d'origen Ethernet està protegida expressament darrere de skb_ensure_writable(skb, 0). El que no estava protegit és la reescriptura opcional de l'adreça de maquinari de l'emissor dins la capçalera ARP —la que activa l'opció --snat-arp—, que escriu amb skb_store_bits() en un desplaçament relatiu a skb->data.

I aquí hi ha el problema, amb les paraules del mateix pedaç: «If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it.» L'arranjament consisteix a assegurar-se que el rang és escrivible abans d'escriure-hi. El CNA del nucli li posa 8,8 amb S:C, abast canviat: el dany no es queda dins del component que té l'error. Quan el destí de l'escriptura és la pàgina d'un fitxer que algú ha importat amb splice, aquesta lletra deixa de ser teòrica.

Si administres Proxmox VE, la paraula ebtables et sona, i no pas de lluny: el tallafoc del clúster porta l'opció ebtables a 1 per defecte a /etc/pve/firewall/cluster.fw, i el tallafoc basat en nftables continua marcat a la documentació de la 9.2 com a technology preview, amb l'avís que no és apte per a producció. El que corre per defecte és el de sempre.

La part honesta: les regles que escriu el tallafoc de Proxmox no són regles de SNAT a la taula nat, que és l'únic lloc on viu l'objectiu vulnerable. Que el teu node tingui ebtables actiu no vol dir que estigui executant aquest codi. Vol dir que el mòdul és al nucli que arrenques, i que qui pugui crear regles de pont —amb CAP_NET_ADMIN al seu propi espai de noms de xarxa, i amb el mòdul carregat o carregable des d'allà— podria arribar a aquest objectiu encara que tu no el facis servir mai. No ho hem reproduït. Es comprova amb ebtables -t nat -L. I si avui no pots reiniciar, hi ha sortides provisionals que no toquen el nucli arrencat: impedir que aquest mòdul es carregui, o tancar els espais de noms d'usuari no privilegiats amb user.max_user_namespaces. Totes dues trenquen coses segons quines càrregues, així que es proven abans.

«Local», en un hipervisor, no significa el que sembla

Els dos vectors comencen igual: AV:L, accés local. En un portàtil això vol dir que algú ha de ser a dins. En un amfitrió amb convidats vol dir una altra cosa: «local» és el conjunt de tots els que comparteixen aquest nucli. I aquí la diferència entre un contenidor i una màquina virtual deixa de ser una preferència de desplegament.

En un contenidor LXC no hi ha un nucli convidat: hi ha el teu. Una escalada local dins d'aquest contenidor apunta al mateix binari que arrenca el node. Una VM amb KVM sí que té el seu propi nucli, que també és Linux i que també pot estar en rang: aquí el mateix error és el que el CNA puntua en posar PR:L al costat de C:H/I:H/A:H, i això, traduït, és passar de «tinc execució dins de la teva aplicació web» a «soc root en aquesta màquina». I AF_ALG, per cert, és la cara en espai d'usuari de l'API criptogràfica del nucli: un socket que qualsevol procés local pot obrir. El PR:L del vector ho diu sense adorns.

Que això es converteixi en avaria depèn de qui hagi rebut una shell teva, i això sí que és una decisió teva, presa fa mesos, probablement sense pensar que algun dia es llegiria així.

Quina branca ho arregla, i per què la teva pot no ser a la llista

Les versions corregides de CVE-2026-53266, llegides dels rangs de la fitxa: 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36 i 7.0.13. Llegeix-la un altre cop i busca-hi una 6.17. No hi és. La 6.17 no és una branca amb manteniment llarg, així que l'arranjament apareix a la 6.18.36 i no a una 6.17.x: qui arrenqui una 6.17 no es posa al dia actualitzant dins de la seva branca, sinó canviant de branca o depenent que la seva distribució li retroporti el pedaç.

Amb CVE-2025-39964 passa el contrari, i per un cop és bona notícia: l'arranjament va entrar a 6.17-rc7, de manera que les versions corregides són 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49 i 6.16.9, i qualsevol nucli 6.17 o posterior ja el porta de fàbrica. Portat a Proxmox VE, depèn de la versió i això importa: la 9.1 porta 6.17.2 per defecte i la 9.2 la sèrie 7.0, de manera que allà el del 3,3 ja està tancat; a la 9.0 (6.14) i a la 8.x (6.8) no ho està, i aquestes són en rang de tots dos. Del de 8,8 no se'n lliura cap quedant-se dins de la seva branca: a 6.17 no hi ha arranjament de sèrie, i a la 7.0 cal ser a 7.0.13 o per sobre. A Debian, el paquet linux tanca tots dos a 6.1.187-1 (bookworm) i 6.12.107-1 (trixie).

Amb un matís que ja vam explicar sencer en el seu dia i que aquí només es recorda: un node Proxmox no arrenca el nucli de Debian, així que el número que surt al butlletí de Debian no és el número que has de comparar. El que mana és el que retornin uname -r i pveversion -v a la teva màquina, aquesta tarda, no el de la notícia.

Reculls primer o apedaces primer?

Les dues entrades d'avui porten la marca de triatge forense. Al JSON del catàleg —versió 2026.09.18, 1.715 entrades— la duen 57, i val la pena mirar d'on surt aquest 57: cap entrada anterior a l'1 de juliol de 2026 no la té, perquè el camp no existia. De les 85 altes posteriors a aquesta data, 57 la porten i 28 no. O sigui que no és una marca rara: és el que CISA posa a dues de cada tres coses que dona d'alta des de l'estiu.

La guia d'implantació que acompanya aquesta marca diu això: «Do not alter or remediate systems prior to evidence/artifact collection when possible.» I distribueix els passos en el temps: delimitar l'abast a les dues primeres hores des de l'alta, recollir les proves entre les 2 i les 24 hores, i pedaçar també entre les 2 i les 24 hores, però després de recollir-les.

Ara ajunta les dues coses. L'arranjament d'un error del nucli és un reinici. I un reinici s'emporta la memòria, la taula de processos, els sockets oberts, els mòduls tal com estaven carregats, el contingut de /proc, el que hi hagués a tmpfs i qualsevol cosa que no arribés mai a tocar el disc. L'acció que et treu el problema és també la que esborra mitja resposta a «han entrat?». Mitja, perquè el diari persistent, l'auditoria i el que hagis enviat fora sobreviuen al reinici. El que no sobreviu és el que només existia a la RAM, que sol ser justament el que voldries mirar.

La directiva obliga les agències federals dels Estats Units; a tu no t'obliga ningú. Però el catàleg el fa servir tothom, incloses les auditories que et passen a tu, i el dilema és idèntic amb directiva o sense. Amb el dilema s'hi pot viure. Amb resoldre'l a les tres de la matinada, qui estigui de guàrdia, sense res escrit i amb un termini a sobre, s'hi viu força pitjor.

L'ordre que seguim nosaltres

1. Em toca? uname -r a cada amfitrió, pveversion -v als nodes Proxmox, dpkg -l 'linux-image-*' a Debian. Es compara amb les versions corregides de dalt i amb el paquet de la teva distribució. Mai amb el titular.
2. Qui comparteix nucli? qm list i pct list diuen quants convidats porten el seu propi nucli i quants fan servir el teu. A mà s'hi afegeix el que no hi surt: qui té shell a l'amfitrió, quin procés executa codi de tercers, quin runner d'integració contínua compila el que li enviïn.
3. Si estàs afectat, mirar abans de tocar. Seguint l'ordre de volatilitat de la RFC 3227 (2002), tot i que saltant-nos-en el primer esglaó, que és la memòria: processos i el binari real darrere de cadascun (ps -ef, ls -l /proc/*/exe), sockets i de qui són (ss -tunap), mòduls carregats (lsmod) i el diari del sistema copiat fora de la màquina. Això no és una anàlisi forense —una de debò comença bolcant la memòria en calent i la fa qui en sap—, però és la diferència entre tenir alguna cosa i no tenir res.
4. I llavors sí, el reinici rodat. ha-manager crm-command node-maintenance enable <node>, que mou els serveis gestionats per HA i els torna en desactivar-lo; ceph osd set noout si hi ha Ceph, perquè el clúster no es posi a reequilibrar per un node que torna d'aquí a cinc minuts; actualitzar, reiniciar, i comprovar que el node ha tornat, que hi ha quòrum i que ceph -s dona HEALTH_OK abans de tocar el següent. Un cada vegada, encara que el termini estrenyi.
5. Apuntar l'hora de cada pas. Si d'aquí a un mes algú pregunta què es va fer, quan i qui ho va decidir, aquesta llista és la resposta. I si no n'hi ha, la resposta és que no se sap.

Moure un contenidor és aturar-lo

La migració en viu és una funció de les màquines virtuals. La documentació de Proxmox ho diu de passada, a la pàgina de contenidors, parlant dels «Application Containers» de tipus OCI que acaba d'estrenar en vista prèvia: «While running lightweight "Application Containers" directly offers significant advantages over a full VM, for use cases demanding maximum isolation and the ability to live-migrate, nesting containers inside a Proxmox QEMU VM remains a recommended practice.» Un contenidor es mou aturant-lo.

Aquí apareix una simetria desagradable: els convidats més exposats a un error local del nucli —els que comparteixen el teu— són exactament els que no es poden moure sense aturar-los. L'aritmètica és aquesta, i es planifica en un full abans que arribi el divendres. A la llista s'hi sumen les VMs amb dispositius PCI en passthrough i les que tenen el disc en emmagatzematge local, que tampoc no viatgen en calent. Cadascuna d'aquestes és un minut d'aturada que es decideix en una reunió, no a les tres de la matinada.

I si el clúster no té lloc per funcionar amb un node menys, el reinici rodat es converteix en una aturada a terminis. És la mateixa història que vam explicar sobre la redundància que no sobreviu al procediment i sobre què fa el clúster quan li falta un node: el ferro hi era, el marge també, i el procediment se'ls va menjar.

Quan no faríem res aquest cap de setmana

Els dos errors són locals. Si en aquests amfitrions no hi ha contenidors de tercers, ni shell per a ningú de fora, ni un runner que compili el que li enviïn, ni clients diferents compartint la mateixa màquina, la cadena necessita un primer punt de suport que potser no existeix. Llavors no cremis una finestra de dissabte: programa el reinici rodat per a la finestra normal, amb el procediment al davant i amb qui toca despert.

Dues coses sí que les faríem avui: comprovar si estàs afectat i mirar el registre. La segona no la demana cap termini: la demana el reinici de dilluns, que ja no et deixarà fer-la.

I una declaració de part, perquè toca: venem guàrdia 24/7. Quan et diem que no cal trucar a ningú un dissabte, estem dient just el contrari del que ens convé. Llegeix-ho amb escepticisme, i decideix tu.

Dues línies noves en una llista, un termini que cau en dilluns i una tecla que arregla i esborra alhora. Res d'això no es decideix bé a les onze de la nit: es decideix al març, quan no passa res i algú s'asseu a escriure el procediment.

El que no afirmem

No hem reproduït cap dels dos errors ni en tenim exploit: CISA diu que hi ha explotació coneguda i no publica com, així que no descrivim una cadena d'atac que no hem vist. El 3,3 del NVD no ens sembla mal calculat: mesura una pregunta diferent de la que estreny. Tampoc no hem avaluat a fons les mitigacions provisionals que esmentem, així que van com el que són, un apedaçament per guanyar hores. No sabem quin paquet concret de Proxmox porta avui l'arranjament de CVE-2026-53266 —el número que cal mirar és el del teu node, no el d'una nota—. La lectura d'ebtables en un node Proxmox és nostra i va acotada més amunt: el mòdul hi és, l'objectiu vulnerable no el fa servir el tallafoc del producte. La directiva BOD 26-04 obliga les agències federals dels Estats Units, no pas una empresa d'aquí. I el punt 3 del nostre ordre no és una anàlisi forense: és recollir quatre coses abans que el reinici se les endugui. Un detall que no sabem explicar i que no amagarem: en aquestes mateixes fitxes del NVD, l'avaluació SSVC que signa CISA el 18 de setembre marca exploitation: none, el mateix dia de l'alta al catàleg d'explotats. El termini mana igualment, però hi és.

Nota de fonts

Tot consultat el 18 de setembre de 2026, sobre les fonts primàries i no sobre cobertures de segona mà. Un: el fitxer JSON del catàleg de vulnerabilitats explotades de CISA, descarregat aquesta tarda (versió 2026.09.18, publicada a les 13:49 UTC, 1.715 entrades): d'allà surten les dues altes d'avui, els seus terminis al 21 de setembre, la marca de triatge forense i el recompte propi: 57 entrades la duen, totes de l'1 de juliol de 2026 endavant, sobre 85 altes en aquest període. Dos: l'API del NVD per a CVE-2025-39964 i CVE-2026-53266: dates de publicació, els vectors CVSS amb el seu origen —a CVE-2025-39964, el primari del NIST (3,3) i el del CNA del nucli (7,8); a CVE-2026-53266 només el del CNA (8,8), perquè el NVD no ha publicat avaluació primària—, les classes CWE-362 i CWE-787, que a la fitxa signa CISA-ADP i no el NVD, i els rangs de versions afectades d'on surten les llistes de versions corregides. Tres: els missatges dels dos pedaços del nucli, citats tal qual. Quatre: el rastrejador de seguretat de Debian per a les dues fitxes (paquet linux, versions corregides per publicació i la nota que l'arranjament d'af_alg va entrar a 6.17-rc7). Cinc: la guia d'implantació de la BOD 26-04 de CISA, d'on surt la frase sobre no remeiar abans de recollir i els trams horaris dels passos. Sis: la documentació de Proxmox VE —capítol del tallafoc (opció ebtables i estat del tallafoc nftables), capítol de contenidors (la frase sobre migració en viu) i capítol d'HA (l'ordre de mode manteniment)— i la pàgina Roadmap per als nuclis per defecte de la 9.1 i la 9.2. Set: el manual d'ebtables per a l'opció --snat-arp, i la RFC 3227 per a l'ordre de volatilitat. El que és opinió nostra i va marcat com a tal al cos: que una sola xifra no pot contestar tres preguntes; la lectura de «local» en un amfitrió amb convidats; la simetria entre allò més exposat i allò que no es pot moure en calent; l'ordre de cinc passos; i els casos en què no faríem res aquest cap de setmana.

Imatge de portada: fotografia d'un servidor de dos sòcols amb els seus bancs de memòria, de 极客湾Geekerwan (Wikimedia Commons, CC BY 3.0), retallada per nosaltres. Els textos i la marca els afegim a sobre.