Il 13 agosto 2026 la TrendAI Zero Day Initiative ha reso pubblico l'advisory ZDI-26-575, che documenta una vulnerabilità di escalation di privilegi locale nel Linux Kernel. La falla risiede nel Net Scheduler Packet Classifier API, componente del sottosistema traffic control (tc), ed è causata da una race condition Time-Of-Check Time-Of-Use (TOCTOU) per mancanza di locking corretto durante operazioni su oggetti condivisi. L'annuncio conclude una finestra di disclosure coordinata di circa sette settimane: la segnalazione al vendor risale al 25 giugno 2026.
- L'advisory ZDI-26-575 documenta una vulnerabilità LPE nel Linux Kernel pubblicata il 13 agosto 2026, con segnalazione al vendor il 25 giugno 2026.
- Il meccanismo è una race condition TOCTOU nel traffic classifier del Net Scheduler: lettura inconsistente del numero di chiavi pedit tra verifica e uso durante l'offload hardware.
- L'attaccante deve già disporre di capacità di eseguire codice con privilegi elevati sul sistema target per sfruttare la falla.
- Il commit 8b519cb nel repository ufficiale torvalds/linux corregge la vulnerabilità introducendo la funzione
tcf_pedit_nkeys_locked()con serializzazione viaspin_lock_bh.
Il meccanismo: una TOCTOU "classica" nel sottosistema tc
Il nucleo della vulnerabilità è una race condition di tipo Time-Of-Check Time-Of-Use nel traffic classifier del Net Scheduler Linux, nello specifico nel modulo act_pedit che gestisce le operazioni di packet editing nel framework traffic control. La ZDI descrive la falla con precisione: "The specific flaw exists within the traffic classifier. The issue results from the lack of proper locking when performing operations on an object." L'accesso concorrente al campo tcfp_nkeys — il numero di chiavi di modifica del pacchetto — avviene senza adeguata protezione, permettendo che il valore letto in fase di verifica differisca da quello effettivamente usato nell'operazione successiva.
Questa inconsistenza si manifesta nel contesto dell'offload hardware del traffic control, dove il kernel delega a componenti NIC l'elaborazione delle regole tc. Durante il calcolo del numero di azioni da offlodare, il codice itera sulle estensioni e sulle azioni pedit senza garantire la stabilità del contatore di chiavi. Il risultato è un heap out-of-bounds write: la scrittura oltre i limiti dell'area allocata per le strutture di editing dei pacchetti.
L'advisory ZDI è chiaro sulle conseguenze: "An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the kernel." L'esecuzione di codice in kernel mode rappresenta il completamento dell'escalation: dall'accesso locale già privilegiato al controllo totale del sistema.
Il fix tecnico: locking manuale, non astrazione automatica
La correzione nel repository ufficiale di Linus Torvalds, commit 8b519cb con messaggio "net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", adotta un approccio esplicito e manuale alla sincronizzazione. Il cambiamento introduce la funzione tcf_pedit_nkeys_locked(), accompagnata dall'annotazione lockdep_assert_held(&a->tcfa_lock) che impone la verifica statica del lock. Il commento nel commit è inequivocabile: "Must be called with act->tcfa_lock held to ensure consistency of parallel reads of the same action's pedit keys."
Le chiamate esistenti a tcf_pedit_nkeys() nelle funzioni di offload tcf_offload_act_num_actions_single() e tcf_exts_num_actions() vengono sostituite con la versione locked, avvolte in coppie spin_lock_bh(&act->tcfa_lock) e spin_unlock_bh(&act->tcfa_lock). La scelta di spin_lock_bh — che disabilita i bottom half ma non i softirq in modo indiscriminato — indica che gli sviluppatori hanno bilanciato la necessità di esclusione mutua con il requisito di non bloccare eccessivamente il percorso di rete.
Questo pattern è rivelatore. Dopo tre decenni di sviluppo del kernel Linux, il sottosistema networking continua a richiedere interventi manuali di locking piuttosto che beneficiare di astrazioni automatiche che prevengano classi intere di race condition. La TOCTOU corrette non è frutto di un redesign architetturale, ma di un'audit mirata che ha identificato una specifica finestra di vulnerabilità e l'ha chiusa con le primitive esistenti.
Perché il perimetro di rischio è più ampio del singolo server
L'advisory specifica che l'attaccante deve già avere capacità di eseguire codice high-privileged sul sistema target. Questa condizione iniziale non sminuisce la gravità: in ambienti multi-tenant, piattaforme containerizzate e infrastrutture cloud, l'escalation da container a host o da utente privilegiato a kernel mode è un salto critico nel modello di minaccia.
I sistemi che centralizzano la gestione del traffico di rete tramite tc — server edge, nodi Kubernetes con policy network elaborate, host di virtualizzazione con SR-IOV o offloading hardware — espongono il sottosistema net/sched a un attack surface significativo. Il traffic control è un componente abilitato di default in molte configurazioni enterprise e cloud, non un modulo opzionale raramente caricato.
Il dossier non documenta versioni specifiche del kernel affette, né la presenza di exploit in-the-wild. Questi limiti rendono impossibile quantificare l'esposizione reale, ma non attenuano la criticità intrinseca di una LPE kernel-mode in un sottosistema di rete così diffuso.
Cosa fare adesso
Le seguenti azioni derivano direttamente dai fatti documentati nelle fonti:
- Verificare la presenza del commit 8b519cb nella propria baseline kernel: il fix è nel repository torvalds/linux e deve essere integrato nelle release delle distribuzioni.
- Monitorare le release notes dei vendor di distribuzione enterprise (Red Hat, SUSE, Canonical, Debian) per l'applicazione del patch specifico al modulo
act_pedit. - Valutare la priorità di patching in base all'utilizzo effettivo di tc con offload hardware: i sistemi che non attivano questa configurazione hanno esposizione ridotta, sebbene il sottosistema net/sched rimanga presente.
- Attendere l'assegnazione di un identificatore CVE per tracciabilità nel proprio sistema di vulnerability management, dato che l'advisory ZDI non esplicita un CVE al momento della pubblicazione.
"An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the kernel." — ZDI Advisory ZDI-26-575
FAQ
Perché il kernel Linux continua a presentare race condition TOCTOU dopo decenni di sviluppo?
Il sottosistema networking opera in percorsi ad alta frequenza e bassa latenza dove l'overhead del locking è storicamente minimizzato. La scelta di spin_lock_bh nel fix attuale, piuttosto di un redesign del modello di concorrenza, conferma che le ottimizzazioni prestazionali continuano a prevalere sulle garanzie automatiche di correttezza.
L'assenza di CVE e CVSS nell'advisory ZDI limita la gestione della vulnerabilità?
La mancanza di un identificatore CVE e di un punteggio CVSS numerico nel testo estratto dall'advisory ZDI-26-575 complica l'integrazione nei sistemi automatizzati di prioritizzazione, ma non riduce la severità tecnica documentata: LPE con esecuzione in kernel mode è intrinsecamente critica.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- http://www.zerodayinitiative.com/advisories/ZDI-26-575/
- http://www.zerodayinitiative.com/advisories/published/
- http://www.zerodayinitiative.com/advisories/upcoming/
- https://github.com/torvalds/linux/commit/8b519cbcabe836a441369fbec1a8a6518a709251
- https://www.trendmicro.com/
- https://www.trendmicro.com/en_us/business/products/one-platform.html