El 21 d'octubre, la Zero Day Initiative de Trend Micro va enviar cinc informes d'errades del nucli de Linux a l'equip de seguretat del projecte i, per error, a les llistes públiques de desenvolupament. Tres portaven codi de prova complet. Cap no té CVE, i una ja ha servit per aconseguir root a AlmaLinux, Debian i Ubuntu amb nuclis que són en producció ara mateix. Si aquesta setmana ho preguntes al teu escàner de vulnerabilitats, et dirà que no hi ha res crític. I tindrà raó, perquè no hi ha cap número a comptar.
El que va sortir, i per on
La seqüència és curta. El 20 d'octubre a les 00:17 UTC va sortir un informe sobre ConnMan, el gestor de connexions que corre en espai d'usuari. El 21 d'octubre en van sortir cinc més, aquests sí del nucli, adreçats a l'equip de seguretat del projecte i —per error— amb les llistes públiques en còpia, entre elles la llista general del nucli i la de xarxa. El 22 d'octubre ho va recollir Phoronix i Greg Kroah-Hartman, el segon de bord del nucli, va anar contestant als informes per assenyalar el que acabava de passar: eren públics i havien arribat sense pedaç.
El que et toca no és el de 9,0
Si ordenes aquesta taula per la puntuació, comences pels dos nous i t'equivoques de lloc. Els dos nous són de ksmbd, una peça que cal haver encès a mà i que la majoria no té. El que de debò mou el dia és el 7,8.
skb_zerocopy() no arrossega una marca que indica que un fragment de dades està compartit. Sense aquesta marca, el desxifratge d'ESP acaba escrivint sobre dades que viuen a la memòria cau de pàgines, de manera que un procés sense privilegis modifica un fitxer que pot llegir però que no té permís per obrir en escriptura. És la mateixa família que Dirty Pipe, i d'aquí a root hi ha un pas curt. A les proves de TuxCare aquest pas es va fer a AlmaLinux 8, 9 i 10, CloudLinux 9 i 10, Debian 12 i 13, i Ubuntu 24.04 i 26.04. No són branques de laboratori: són els nuclis que arrenquen els teus servidors. I esquiva l'arranjament de Dirty Frag (CVE-2026-43284) del maig: AlmaLinux el porta aplicat a les tres versions, i cau igual.
Ara el matís que no surt als titulars i que decideix si això et lleva la son: és local. Cal que algú ja pugui executar codi sense privilegis en aquella màquina. Així que la pregunta no és la puntuació, és qui té una consola en aquell servidor. Un executor d'integració contínua que executa branques de qualsevol, un allotjament compartit —que CloudLinux sigui a la llista de distribucions provades no és casualitat—, contenidors amb càrrega de tercers o un servidor amb comptes de desenvolupament: allà això és urgent avui. Una màquina on entren dos administradors amb clau i ningú més és una altra conversa. CVSS no sap quina de les dues és la teva. Tu sí.
El número no és un avís: és un rebut
La política d'assignació del projecte mateix ho diu sense embuts: «No s'assignarà automàticament cap CVE a problemes de seguretat sense corregir del nucli de Linux; l'assignació passarà automàticament només després que existeixi un arranjament i s'hagi aplicat a un arbre estable». I hi afegeix una altra regla amb què molta gent ensopega: «No s'assignarà cap CVE a un problema trobat en una versió del nucli que l'equip de Stable/LTS no mantingui activament».
Ens sembla una política correcta i la defensem: inflar el recompte amb identificadors d'errades que encara ningú no pot arreglar no protegeix ningú, i alimenta la ficció que un número és una solució. Però té una conseqüència que es nota el dimarts al matí. Mentre dura la finestra —de «això és públic» a «això és en una branca estable»— no hi ha número, i la teva cadena d'eines no té on posar-lo. L'escàner compara versions instal·lades contra una base de dades de CVE. L'informe mensual compta CVE. L'acord de nivell de servei de pedaçat es mesura en dies des de la publicació del CVE. El tauler que veu el comitè diu zero crítiques, i diu la veritat: no hi ha cap crítica amb identificador.
Posa les dates al costat i la finestra deixa de ser un detall. La política de divulgació de ZDI són 120 dies, de manera que la data límit per publicar els avisos oficials dels cinc informes del nucli cau el 18 de febrer del 2027. El CVE arribarà quan l'arranjament entri en una branca estable, abans o després d'aquella data, però sempre després de l'arranjament. El que apareixerà al teu escàner no és una alerta d'alguna cosa que has de fer: és la confirmació d'alguna cosa que ja va passar. El número no és un avís. És un rebut.
ksmbd no és Samba, i probablement ni el tens
ksmbd és el servidor SMB3 que corre dins del nucli. No és Samba, que viu en espai d'usuari i és el que hi ha a l'enorme majoria de llocs on algú comparteix una carpeta. Va néixer buscant rendiment, i el seu repartiment està explicat a la documentació del nucli: les operacions lligades al rendiment —obrir, llegir, escriure, tancar— van a dins; la gestió DCE/RPC i de comptes es queda fora perquè és la part que, cita literal, «històricament ha donat lloc a nombrosos desbordaments de memòria intermèdia i errors de seguretat perillosos». La frase fa anys que hi és.
A la configuració del nucli l'opció s'anomena, literalment, «SMB3 server support (EXPERIMENTAL)». Debian i Ubuntu distribueixen el mòdul, però inert: no fa res fins que algú instal·la ksmbd-tools, configura un recurs i arrenca el servei. AlmaLinux i CloudLinux directament no el construeixen, i Red Hat tampoc no el construeix ni el distribueix. Per tenir això encès cal haver-lo encès a propòsit. El més probable, doncs, és que aquests dos nous no vagin amb tu.
Hi ha un detall del primer que val la pena mirar, perquè contradiu el que un esperaria. La documentació diu que ksmbd implementa els dialectes 2.1, 3.0 i 3.1.1, «excloent intencionadament el dialecte SMB1, vulnerable en seguretat». I tanmateix el disparador descrit és una ràfega de paquets SMB1 curts seguida d'un SMB2 a la mateixa escriptura TCP, que fa que un fil acabi tractant dades d'SMB1 amb un manejador d'SMB2 i llegint més enllà del final de la memòria intermèdia curta. Les dues coses són certes: ksmbd no descarta SMB1, l'implementa en part a propòsit —manté una taula d'operacions SMB1 amb el seu manejador de negociació— perquè la negociació multiprotocol d'SMB1 és la via legítima per la qual un client antic puja a SMB2. L'errada no és al dialecte que suportes ni al que rebutges, sinó a l'instant en què es canvia d'un a l'altre. Excloure un dialecte de la llista de funcions no el treu del codi.
Què comprovar, i les trampes que té comprovar-ho
A cada màquina Linux que comparteixi fitxers:
lsmod | grep ksmbd
modinfo ksmbd 2>/dev/null | head -2
systemctl is-enabled ksmbd 2>/dev/null
ss -Hltnp 'sport = :445'
grep -E 'CONFIG_SMB_SERVER(_SMBDIRECT)?=' /boot/config-$(uname -r) \
|| zcat /proc/config.gz | grep -E 'CONFIG_SMB_SERVER(_SMBDIRECT)?='Les trampes, per ordre de probabilitat que et mosseguin. Que lsmod no retorni res no tanca l'assumpte: si el nucli es va compilar amb CONFIG_SMB_SERVER=y el servidor va a dins i no apareix com a mòdul. modinfo contesta millor que la configuració: =m diu amb què es va compilar el nucli, no quin fitxer està instal·lat —a Ubuntu el mòdul viu en un paquet a part de mòduls extra, i sense aquell paquet un modprobe falla—. I a ss, fes servir el filtre de port en lloc d'un grep ':445', que també casa amb el 4450 i amb el 4455; a més, per a ksmbd la columna de procés sortirà buida, perquè qui escolta és el nucli i no hi ha procés a què apuntar. Si esperes veure-hi un nom i no el veus, no vol dir que no hi hagi ningú escoltant.
Per al segon error cal a més una targeta amb RDMA i CONFIG_SMB_SERVER_SMBDIRECT. Un ls /sys/class/infiniband buit apunta que no, amb la reserva que aquell directori pot no existir si el nucli RDMA no està carregat, i que RoCE per programari es pot crear després sense cap maquinari.
Si surt que sí i no el necessites, el que sosté no és descarregar el mòdul: modprobe -r ksmbd falla si està en ús i res no impedeix que es torni a carregar al següent arrencada. El que sosté és emmascarar el servei i moure el recurs a Samba. No perquè l'espai d'usuari sigui màgic —Samba té el seu propi historial d'errades—, sinó perquè un desbordament dins del nucli corre amb el privilegi del nucli i un en un dimoni corre amb el del dimoni. Si no pots apagar-lo avui, la mitigació és de xarxa: el 445 no hauria de ser abastable des d'internet, ni des de la VLAN de convidats, ni des de tota l'oficina per costum. Això s'arregla amb una regla, no amb una finestra de manteniment.
I la limitació honesta del mètode: aquestes línies contesten sobre aquella màquina. La pregunta que importa és sobre totes. El salt d'una màquina al parc sencer és on es veu si tens un inventari que contesta o un full de càlcul que algú va actualitzar al març.
La finestra la va obrir un camp de còpia
L'exposició d'aquesta setmana no la va obrir cap atacant ni cap error de disseny del nucli. La va obrir un camp de còpia en un correu electrònic. Un procediment de divulgació coordinada, que existeix precisament perquè els detalls no surtin abans que l'arranjament, es va saltar tot sol per un destinatari de més.
A l'estudi de referència sobre per què cauen els serveis grans li passa una cosa semblant: en dos dels tres serveis analitzats, l'error de l'operador és la primera causa de caiguda, i més de la meitat d'aquests errors —en un cas, gairebé tots— van ser errors de configuració. Aquí no ha caigut res, però la forma és la mateixa. Els processos els executen persones, i una persona es pot equivocar al camp de destinació.
El que sí que es dissenya és el que ve després. Comença per un inventari que contesta: no una llista d'actius, sinó una font de veritat que sàpiga quin nucli arrenca cada node i quins serveis escolten a quin port. Nosaltres portem NetBox per a això i Zabbix amb SmokePing per a la telemetria; el que importa no és l'eina, és que «quantes màquines tenen això?» es contesti consultant alguna cosa en lloc de preguntant a algú. Segueix per l'exposició, que és l'únic control que no depèn que existeixi un pedaç: el port que no és abastable no t'obliga a córrer, i decidir qui abasta què és feina de ciberseguretat i de Zero Trust —ningú no arriba a un servei per ser dins de l'oficina, sinó perquè li correspon—.
I acaba en l'únic dels tres que no s'automatitza: algú que estigui llegint el canal de la teva distribució quan l'arranjament aparegui, decideixi si aquesta nit toca o no toca, i deixi escrit per què. Això és el que venem com a suport IT 24x7, i ho venem amb el límit al davant: no existeix cap escàner que vegi el que no té número, i nosaltres tampoc no en tenim cap. El que es pot sostenir és la guàrdia, i que a les dues de la matinada hi hagi algú que distingeixi entre el que pot esperar a dimarts i el que no.
La pregunta incòmoda
No és «tinc ksmbd?». Aquesta es contesta en trenta segons i amb força probabilitat amb un no. La pregunta incòmoda és quant va trigar la teva organització a contestar-la sense un CVE per enganxar a un cercador. Si la resposta és «encara no ho sé», el forat no és a SMB: és que la teva capacitat de dir alguna cosa sobre el teu propi parc depèn que algú de fora emeti un número.
Ja ens vam trobar amb el mateix forat quan vam explicar que les versions corregides d'un avís no es corresponen amb cap branca que arrenqui un node Proxmox: el butlletí et diu que l'errada existeix, no si el binari que tu arrenques la porta. I quan l'arranjament arribi, arribarà amb el seu propi cost, perquè ja vam veure que pedaçar el nucli és reiniciar, i reiniciar esborra la prova. Aquesta vegada ni tan sols hi ha butlletí: hi ha sis correus que van sortir per la porta del costat.
Si vols que mirem amb tu què escolta avui al 445 de la teva xarxa, qui té consola als servidors on importa i quant trigues a contestar la següent pregunta d'aquest tipus, en parlem. L'entregable és una llista, no un projecte.
Fonts. La cronologia (informe de ConnMan el 20 d'octubre del 2026 a les 00:17 UTC; cinc informes del nucli el 21 d'octubre a l'equip de seguretat i, per error, a llistes públiques; cobertura i resposta de Greg Kroah-Hartman el 22 d'octubre), els sis identificadors ZDI-CAN amb les seves puntuacions i estat d'arranjament, la resposta de Namjae Jeon sobre el commit 68f410faedaf, la branca de treball de Stefan Metzmacher per al cicle 7.5, la data límit de divulgació del 18 de febrer del 2027 i els resultats d'explotació amb skb_zerocopy —root verificat a AlmaLinux 8, 9 i 10, CloudLinux 9 i 10, Debian 12 i 13 i Ubuntu 24.04 i 26.04, esquivant l'arranjament de Dirty Frag (CVE-2026-43284)— procedeixen de Phoronix, TuxCare i Security Online. TuxCare comercialitza pedaçat del nucli sense reinici: el seu interès comercial queda declarat, igual que el nostre. La política d'assignació de CVE i les dues citacions procedeixen de la documentació del nucli; la descripció de ksmbd, el repartiment entre nucli i espai d'usuari, l'opció «SMB3 server support (EXPERIMENTAL)» i els dialectes suportats, de la documentació de ksmbd. Que Red Hat no construeix ni distribueix ksmbd està publicat a la seva base de coneixement. L'existència d'una taula d'operacions SMB1 amb el seu manejador de negociació a ksmbd és comprovable al codi mateix del nucli (fs/smb/server/smb_common.c). L'estudi sobre causes de caiguda és Oppenheimer, Ganapathi i Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?» (USENIX USITS, 2003). La lectura que l'error local importa segons qui tingui consola, l'advertiment sobre les trampes de cada ordre de comprovació, la tesi que el número és un rebut i no un avís, i la lectura del canvi de taula d'operacions són criteri nostre, no afirmacions de les fonts citades. everyWAN presta serveis gestionats de suport i seguretat: el conflicte d'interès queda declarat. Foto de portada: «Front of server racks at NERSC», de Derrick Coetzee, Wikimedia Commons, CC0 1.0.
Microsoft 365
ES 
CAT 
EN