Panico paura. 79 bug trovati nel kernel Linux dalla AI

Greg Kroah-Hartman · Kernel Recipes 2026 · 29 settembre 2026 · 57 min Video completo — Kernel Recipes

In sintesi

Anthropic ha annunciato 79 vulnerabilità trovate nel kernel Linux da un suo strumento basato su LLM. Kroah-Hartman, che ha avuto accesso ai dati grezzi, li ha esaminati uno per uno: alla fine restano 10 correzioni reali, cioè circa un'ora di sviluppo del kernel. Il panico è fuori posto. Quello che serve è applicare le patch, perché tra la scoperta di una vulnerabilità e il primo tentativo di sfruttarla ora passano meno di zero giorni.

1. Si parte da 55 CVE a settimana

Un anno fa Greg KH diceva a una conferenza di sicurezza: "Il kernel Linux fa 50 CVE a settimana, non è assurdo?" (momento 1:28). Oggi siamo a 55. Le notizie arrivano dalla lista ufficiale dei CVE del kernel, che spiega anche come funziona il processo CNA.

La cosa interessante è che l'infrastruttura, costruita anni fa da lui e Lee Jones per gestire quantità "piccole" di CVE, regge: gli altri Numbering Authority stanno rifacendo i conti in panico, il kernel continua a macinare. "Una CVE al nostro livello è un bug che può far crashare il sistema. Il mio ritornello sarà sempre lo stesso: non fate il panico" (2:32).

2. La telefonata di gennaio

A inizio anno riceve una chiamata: Anthropic sta per rendere pubblica la scoperta di 79 bug nel kernel e gli dà accesso ai dati grezzi. Lo studio si basa su un framework chiamato Mythos.

La tecnica dietro, però, non ha nulla di nuovo. Dieci anni fa Sasha Levin e Julia Lawall avevano già proposto l'idea: prendere le correzioni di bug del passato e verificare dove lo stesso tipo di fix non è stato applicato altrove. È la logica alla base di Coccinelle, lo strumento di analisi statica di Julia che il kernel usa da decenni. Gli autori dello studio, dice Greg, "non ci hanno nemmeno citati" (3:10).

"Il codice è un pattern logico, e il fuzzy pattern matching ci funziona benissimo. È analisi statica, niente di magico" (4:04).

3. I 79 bug, uno per uno

Questa è la parte che vale la pena di leggere con calma (audit completo da 5:30):

Due dettagli divertenti. Il modello, quando gli chiedi un bug, "ci prova davvero tanto": legge le nostre mailing list e restituisce bug che altri hanno già segnalato e corretto, presentandoli come scoperta. E gli LLM non sanno contare: il tarball prometteva 79 bug, le correzioni erano 20.

Cosa c'era dentro quei 20 fix

Sette riguardavano il montaggio di immagini di file system taroccate da root, il classico errore da principiante che viene bollato come non-sicurezza praticamente ogni settimana (6:52). Poi un caso di iniezione di pacchetti che richiede root e strumenti di debug. Due bug no-MMU, uno dei quali riguardava io_uring sistemi dove, ammette, "nessuno usa io_uring" — il modello ha però costruito una VM, scritto un test case e trovato un bug in /dev/zero vecchio di sei anni (7:42).

Sei bug in SCTP, protocollo pensato per reti enterprise su canali autenticati: "un utente non fidato non esiste" (9:01). Due problemini IPv6 che ha dovuto convintissimamente difendere davanti ai maintainer di rete. Un bug su un driver GPU per utente locale malevolo, con un utente del genere sul desktop "puoi fare molto peggio di così" (9:49).

Il conto finale: 10 correzioni reali. Con il kernel che gira a circa 10 patch all'ora, l'intera campagna di marketing equivale a un'ora di sviluppo (10:03).

4. Il numero che spaventa davvero

Qui la talk cambia registro (11:22). Fino a poco tempo fa servivano in media 63 giorni fra la scoperta di una vulnerabilità e il primo tentativo di sfruttarla. Oggi il valore è -7 giorni: si viene attaccati prima ancora che la patch sia distribuita.

Gli LLM sono strumenti stupidi ma testardi, e hanno una capacità nuova: agganciare insieme problemi minuscoli per arrivare all'accesso. Ogni bug minore conta, quindi tutti devono aggiornare gli stable tree. La conclusione di Greg è scomoda ma onesta: il software funziona, non è stato progettato per una sicurezza perfetta, e il conto è arrivato. "Le banche mi dicono finalmente che aggiorneranno il software: la cosa che vi ripetiamo da 15 anni, la farete. Evviva."

5. L'argomento che spegne il panico: i fuzzer

Sei o sette anni fa il refrain era: "i fuzzer ci stanno colpendo, moriremo" (12:44). È finito come sappiamo: ci si è seduti e si è fatto il lavoro, e i fuzzer continuano a girare ogni giorno senza più allarmismi.

Gli LLM funzionano allo stesso modo, con un vantaggio in più: raggiungono path di codice che un fuzzer non può toccare perché lui deve aspettare che i dati entrino da qualche parte (14:00).

L'esempio concreto è rsync: Andrew Tridgell e altri si sono seduti con questi tool, hanno sistemato tutto, hanno fuzzato a maniera, hanno costruito nuova infrastruttura. L'ultima versione ora passa pulita da tutti gli scanner (13:17). Stessa storia per diversi progetti della CNCF. Quando correggi tutto, il flusso si ferma.

6. Metà delle patch è sbagliata

Questa è la parte meno citata e più utile della presentazione. Greg ha sottoposto un insieme di patch generate da LLM a sei studenti di dottorato (19:27). Risultato: metà di quelle che sembrano corrette, che vogliono essere corrette e che ti convincono, non lo sono. Non si applicano, non risolvono il problema, il problema non esiste, il path non è raggiungibile. A volte sono neppure questioni di sicurezza.

"Hanno ingannato anche me," ammette.

I pattern da imparare a riconoscere (20:48):

• la sostituzione di mutex_unlock con mutex_destroy, un errore ricorrente che introduce un bug vero
• changelog lunghi e fioriti ("solo i ragazzi di Btrfs li scrivono così")
• sette righe di commento per due righe di codice
• booleani e flag aggiunti a casaccio, perché il modello ha imparato da un vecchio corpus kernel pieno di cattive abitudini

L'analogia che usa: gli script CGI in Perl di vent'anni fa, insicuri per costruzione, sono dentro i modelli. Chiedigli uno script CGI e otterrai codice insicuro. Vale lo stesso per il kernel.

Il consiglio pratico ai maintainer: cancella il changelog e giudica solo il codice. È quello che hanno fatto gli studenti, e "funziona davvero". Poi chiedi sempre: come l'hai testato? dov'è il reproducer? (24:07)

7. Cosa può andare storto davvero

Gli strumenti perdono i dati (24:26). Qualsiasi cosa carichi te lo ritrovi girata ad altri: è successo a gruppi di ricerca che usavano questi servizi per il proprio lavoro. Per questo il divieto di caricare qualsiasi cosa non pubblica, cominciando dai feed interni di sicurezza.

Il dataset di partenza è probabilmente illegale: la LG AI Research ha dichiarato che solo il 20% dei dati ritenuti aperti è effettivamente utilizzabile, e la Microsoft ha ammesso che nessuno dei creatori viene compensato. Greg ne trae una conseguenza pratica: "Allora nemmeno noi dovremmo pagare."

Il precedente di Coverity insegna che i tassi di falso positivo sopra il 20% rendono uno strumento invendibile (25:50). Quelli di oggi sono al 50%.

E c'è l'asimmetria: le aziende costruiscono pipeline di triaging complesse per i propri sviluppatori, e a noi mandano muri di testo (34:48).

8. Cosa ha messo in piedi il progetto

I maintainer hanno ricevuto strumenti concreti negli ultimi mesi:

• la richiesta di documentare il threat model del proprio subsystem (26:54), con OpenSSF che fornisce uno strumento per generarlo
• il CC obbligatorio ai maintainer sulle segnalazioni di sicurezza (27:59), per diluire il carico
• la regola di chiedere una patch prima di tutto: "Ti facciamo mandare la patch, così avrai tutto il merito" — appellarsi alla vanità funziona
• uno sviluppatore a tempo pieno dedicato alla sicurezza su kernel.org, finanziato da OpenSSF Alpha-Omega (28:58)
• Shashiko, il bot interno per la revisione del codice, da far girare in locale

9. La lista da portarsi a casa

1. Rispondi sempre. Chiedi chiarimenti, il reproducer, il metodo di test. Nessuno ti obbliga ad accettare una patch (24:07).
2. Ignora il doom marketing: non siamo noi i clienti di queste aziende.
3. Gira modelli locali (29:51). Bastano un desktop o una macchina dedicata, sono gratuiti, li lasci lavorare per una notte.
4. Non caricare mai dati non pubblici su nessun servizio.
5. Correggi i bug: una volta risolti, tornano solo se qualcuno li reintroduce.
6. L'etichetta Assisted-by resta il minimo sindacale accettabile (49:12).

10. Dalla domanda del pubblico

Un nuovo contributore ha chiesto come distinguere le patch umane da quelle generate, dato che i programmi di mentorship come LFX producono fix piccoli che somigliano a quelli degli LLM. La risposta di Greg: niente LLM su staging senza hardware e test dimostrato (37:48); manda una o due patch alla volta; vai alle conferenze; rispondi alle email. Sul kernel la fiducia è tutto, e ti assume se sa che sarai lì a sistemarla quando la sbagli, perché "la sbagliamo tutti". Su questo ha scritto due patch rimaste sepolte in Kubernetes perché lo avevano scambiato per un bot (38:44).

Sul "meat puppet", cioè fare da trasmissione passiva tra modello e comunità (42:22): se non sai spiegare cosa hai fatto, non meriti l'Signed-off-by. Un maintainer propone di sostituirlo con Reported-by.

Sulla produttività, Greg non si sbilancia: "Misurarla è come misurare la qualità, lo sai quando lo vedi." Quello che sa è che processa più patch di prima, e non lo considera un buon uso del proprio tempo.

Sui bug introdotti, infine, la domanda giusta di un partecipante: "Mi preoccupa meno il numero di bug trovati che quello introdotti." I grafici sono piatti, il caso fuori scala resta il server SMB della 5.15 (55:14).

11. I prossimi 18 mesi

Greg parla di "18 mesi difficili", poi correggendosi: "forse 12, non lo so" (33:45). I CVE non si stanno riducendo e non è un problema.

La vera sorpresa è la pulizia che sta arrivando: protocolli di rete inutilizzati, driver orfani. Un suo dottorando ha provato a correggere un driver e il maintainer ha risposto "nessuno lo usa più, cancellalo" (33:27). Risultato: tremila righe eliminate. "Hai corretto più bug di chiunque altro."

Sotto il video il dibattito è andato oltre: c'è chi usa l'esempio per contestare l'isolamento delle GPU nei cloud, chi contesta il termine "allucinazione" perché dà troppo credito al modello, chi replica che gli LLM "non mentono né dicono la verità, predicono testo senza nessun rapporto con la realtà". Sul tono della talk le opinioni si dividono, ma il numero che nessuno ha ribattuto resta quello: 10 fix, un'ora di lavoro.

Fonti: video della talk (trascrizione integrale dai sottotitoli), Kernel Recipes 2026, lista CVE del kernel, lista LKML, syzbot menzionato per l'analogia con i report automatici.