Il 13 agosto 2026 il TrendAI Zero Day Initiative ha reso pubblica l'advisory ZDI-26-573, una vulnerabilità critica nel sottosistema KSMBD del kernel Linux che consente lettura arbitraria di memoria kernel a un attaccante remoto non autenticato. Il bug, tracciato come CVE-2026-68431 con punteggio CVSS 3.1 di 9.1, risiede nella funzione init_smb2_rsp_hdr() e colpisce esclusivamente i sistemi con il server SMB in-kernel attivo. La disclosure coordinata arriva 41 giorni dopo la segnalazione al vendor, il 3 luglio 2026, con patch già disponibile ma diffusione di adozione KSMBD ancora non quantificata.
- CVE-2026-68431, CVSS 9.1 CRITICAL: out-of-bounds read nella funzione
init_smb2_rsp_hdrdel Linux Kernel KSMBD, con vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H. - Exploit remoto senza credenziali: l'advisory ZDI specifica che l'autenticazione non è richiesta e che solo i sistemi con ksmbd abilitato sono esposti.
- Root cause documentata: il CVE Record identifica la mancata validazione della dimensione minima PDU per pacchetti SMB2_TRANSFORM_PROTO_NUM su connessioni SMB 2.1, che bypassano il controllo di sicurezza.
- Concatenazione per RCE possibile: la ZDI avverte che la falla può essere sfruttata insieme ad altre vulnerabilità per esecuzione di codice arbitrario in contesto kernel.
Il meccanismo del bug: quando un pacchetto troncato diventa arma
La falla si attiva nel percorso di ricezione SMB2. Il codice valida la dimensione minima PDU solo quando il campo ProtocolId corrisponde a SMB2_PROTO_NUMBER. Quando un pacchetto trasporta invece SMB2_TRANSFORM_PROTO_NUM, il controllo viene bypassato anche se il dialetto negoziato non supporta la gestione dei transform. Su connessioni SMB 2.1, un pacchetto transform deliberatamente troncato raggiunge init_smb2_rsp_hdr(), che lo interpreta come header SMB2 completo e legge oltre i limiti del buffer allocato.
La ZDI descrive la condizione con precisione: "The specific flaw exists within the init_smb2_rsp_hdr functions. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer." Il CVE Record aggiunge il contesto protocollare: "On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation." La combinazione di queste due fonti permette di ricostruire la catena completa: parsing incorretto, mancata validazione del dialetto, lettura fuori bounds.
La gravità deriva dalla posizione architetturale. KSMBD opera in kernel space, non in userspace come Samba. Un bug di parsing protocollare che in un'implementazione tradizionale causerebbe crash o leak di processo, qui espone direttamente la memoria del kernel. Le strutture di rete, le tabelle di routing, i buffer di altri sottosistemi risiedono nello stesso spazio di indirizzamento. La ZDI avverte esplicitamente che un attaccante può concatenare questa information disclosure con altre vulnerabilità per ottenere esecuzione arbitraria in contesto kernel.
La geometria del rischio: chi usa KSMBD e perché è difficile da mappare
KSMBD è l'implementazione in-kernel del server SMB3, introdotta come alternativa leggera a Samba per scenari NAS embedded, sistemi edge e container con esigenze di condivisione file. La promessa era ridurre l'overhead di context switch tra kernel e userspace, eliminando una copia dei dati e migliorando il throughput su hardware limitato. Questo trade-off performance-vs-sicurezza è ora al centro della lettura: l'esposizione diretta in kernel space amplifica l'impatto di ogni bug di parsing.
La base di installazioni effettivamente vulnerabile resta sconosciuta. Il dossier non quantifica quanti sistemi abbiano ksmbd abilitato in produzione, né specifica se prodotti embedded (NAS, router, appliance IoT) integrino il modulo in configurazione predefinita. Le distribuzioni Linux maggiori tendono a mantenere ksmbd come modulo opzionale, ma gli OEM di dispositivi embedded possono compilarlo staticamente. Il campo affectedProduct della ZDI advisory è vuoto; il prodotto va dedotto dal titolo. Non è documentato se il fix sia stato backportato a tutte le versioni kernel LTS.
L'assenza di exploit pubblici o conferme di exploitation in-the-wild nel dossier non riduce la criticità del vector. L'attack complexity è bassa (AC:L nel CVSS), il vettore è di rete (AV:N), nessun privilegio è richiesto (PR:N). Le condizioni per l'exploit sono deterministiche: ksmbd abilitato, connessione SMB 2.1, pacchetto transform malformato. La struttura del protocollo SMB2 è ben documentata; la costruzione del pacchetto troncato non richiede tecniche sofisticate.
"This vulnerability allows remote attackers to disclose sensitive information on affected installations of Linux Kernel KSMBD. Authentication is not required to exploit this vulnerability. However, only systems with ksmbd enabled are vulnerable." — ZDI Advisory ZDI-26-573
Il fix e la sua struttura: due commit per chiudere due varchi
Il mantenimento del kernel Linux ha rilasciato correzione attraverso due commit hash documentati nel CVE Record: b62c510f59803f82f9b4c76ead2a56833b2984c7 e cfc0b8e5080aec87700774e8568765eaa4b7b92b. La prima modifica introduce validazione esplicita dei pacchetti transform dopo la conversione del protocollo. La seconda impone il requisito che le richieste di encryption transform contengano sia il transform header che l'SMB2 header, con controllo dimensionale contro SMB2_MIN_SUPPORTED_PDU_SIZE.
La coordinazione temporale è standard per il programma ZDI: 41 giorni tra segnalazione privata e disclosure pubblica. La ZDI ha pubblicato l'advisory il 13 agosto 2026, lo stesso giorno in cui il CVE Record riporta la disponibilità del fix. Non è documentato nel dossier se esista un periodo di embargo parziale o se il maintainer del kernel abbia ricevuto notifica anticipata rispetto alla pubblicazione coordinata.
La duplice natura della patch riflette la duplice natura del bug: non è sufficiente aggiungere un controllo dimensionale generico, perché il percorso transform ha logiche di parsing diverse dal percorso standard. Il fix deve quindi validare entrambi i rami: le richieste SMB2 ordinarie contro la dimensione minima PDU, e le richieste transform contro la presenza di entrambi gli header. Questa struttura suggerisce che la vulnerabilità sia stata analizzata in profondità prima della correzione, con attenzione a non introdurre regressioni nei percorsi legittimi di encryption.
Cosa fare adesso
- Verificare se ksmbd è attivo: controllare il caricamento del modulo
ksmbde la presenza del processoksmbd.mountd; su sistemi che non utilizzano condivisioni SMB3 in-kernel, disabilitare il modulo è la mitigazione più immediata. - Applicare il fix del kernel: la patch è disponibile attraverso i commit
b62c510f59803f82f9b4c76ead2a56833b2984c7ecfc0b8e5080aec87700774e8568765eaa4b7b92b; verificare con il vendor della distribuzione o il maintainer LTS se l'aggiornamento sia stato backportato alla versione in uso. - Isolare il traffico SMB: su sistemi dove ksmbd non può essere disabilitato per requisiti funzionali, limitare l'esposizione della porta 445 a interfacce fidate e segmenti di rete controllati, riducendo la superficie del vettore AV:N.
- Monitorare le advisory ZDI e CVE: tracciare CVE-2026-68431 per eventuali aggiornamenti su exploit in-the-wild, estensione del campo affectedProduct, o backport aggiuntivi non ancora documentati al momento della pubblicazione.
La scelta architetturale che torna a pesare
La vicenda CVE-2026-68431 non è un caso isolato di codice difettoso: è il punto di confronto tra due filosofie di implementazione. Samba, in userspace da decenni, ha subito vulnerabilità gravi ma limitate dal confine di processo. KSMBD, promosso per efficienza, elimina quel confine e con esso il buffer di sicurezza che conteneva l'impatto. Il kernel Linux ha ora dimostrato di poter patchare rapidamente, ma la domanda rimane aperta su chi monitori la superficie di attacco dei sottosistemi in-kernel meno scrutinati.
Per gli operatori di infrastruttura, il messaggio è duplice: verificare se la leggerezza di KSMBD sia davvero necessaria per il proprio carico di lavoro, e se sì, trattarla come componente critica con ciclo di aggiornamento allineato al kernel, non come servizio periferico. Per gli sviluppatori di sistemi embedded, la scelta di compilare ksmbd come modulo opzionale vs built-in determina la velocità di risposta a future advisory. La ZDI ha consegnato un bug classico di parsing protocollo in un contesto non classico: il kernel. La gravità del CVSS 9.1 riflette quella traslazione, non la novità della tecnica.
FAQ
La vulnerabilità colpisce anche Samba?
No. La falla è specifica di KSMBD, l'implementazione SMB3 in-kernel del kernel Linux. Samba è un progetto separato che opera in userspace e non condivide il codice vulnerabile in init_smb2_rsp_hdr().
È dimostrata l'exploitation per esecuzione di codice remoto?
No. L'advisory ZDI afferma che la vulnerability "can be leveraged in conjunction with other vulnerabilities to execute arbitrary code in the context of the kernel". Non è documentata la disponibilità di exploit RCE autonomi né attacchi in-the-wild al momento della pubblicazione.
Tutti i sistemi Linux sono a rischio?
No. Solo i sistemi con il modulo ksmbd caricato e attivo sono esposti. Il bug non colpisce il kernel generico: dipende dall'abilitazione esplicita del sottosistema server SMB in-kernel, che rimane opzionale nella maggior parte delle distribuzioni.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- http://www.zerodayinitiative.com/advisories/ZDI-26-573/
- http://www.zerodayinitiative.com/advisories/published/
- https://www.cve.org/CVERecord?id=CVE-2026-68431
- https://www.trendmicro.com/