Riepilogo Tecnico: Scoperta Continua di Vulnerabilità nei Sistemi di Servizio LLM tramite Fuzzing

Enunciato del Problema

I sistemi di inferenza e servizio dei Modelli Linguistici di Grande Dimensione (LLM) (ad esempio, vLLM, SGLang) sono diventati infrastrutture critiche per le applicazioni AI moderne. Questi sistemi impiegano ottimizzazioni aggressive come la cache KV, il batching dinamico, la condivisione dei prefissi, la decodifica speculativa e la pianificazione multi-tenant per gestire le esigenze di calcolo e memoria dei modelli di grandi dimensioni. Tuttavia, questa complessità crea una superficie di vulnerabilità distinta e sottotestata all'interno del livello di servizio.

I test di sicurezza attuali si concentrano principalmente sul comportamento del modello (ad esempio, jailbreak, allucinazioni) o sulla conformità delle singole API. Questi approcci non riescono a catturare i guasti derivanti dalla logica di esecuzione del software delle richieste di inferenza valide quando elaborate sotto carichi di lavoro concorrenti realistici. Un'analisi empirica recente indica che oltre il 35% dei bug in questi sistemi si manifesta come anomalie non di crash piuttosto che come arresti improvvisi. Nello specifico, i difetti nello stack di servizio possono portare a:

• Corruzione silenziosa dello stato: Contaminazione incrociata tra richieste in cui l'output di una richiesta viene corrotto dallo stato cache di un'altra.
• Patologie delle prestazioni: Denial of Service del "vicino rumoroso" in cui richieste valide causano un'amplificazione severa della latenza o un crollo del throughput per tenant non correlati senza arrestare il server.
• Guasti di vivibilità ritardati: Crash attivati solo dalla composizione concorrente specifica di richieste valide, violando le invarianti dello schedulatore.

I metodi di test esistenti (valutazioni a livello di modello, test API standard e fuzzers convenzionali) non esercitano sistematicamente il timing, la sovrapposizione e le interazioni di stato condiviso che determinano se un sistema di servizio preserva l'isolamento.

Metodologia: GRIEF

Per colmare questa lacuna, gli autori presentano GRIEF (GReybox Inference Engine Fuzzer), un fuzzer greybox progettato specificamente per i sistemi di inferenza e servizio LLM.

Astrazione Principale: Tracce di Richieste Temporizzate

A differenza dei fuzzers tradizionali che mutano stringhe di byte o prompt isolati, GRIEF tratta le tracce temporizzate di più richieste come input di prima classe. Una traccia è una sequenza di eventi lato client con timestamp che cattura:

• Contenuto della Richiesta: Il prompt e i parametri.
• Struttura di Pianificazione: Quando le richieste si sovrappongono, come competono per lo stato condiviso e i loro eventi di ciclo di vita (INVIA, ANNULLA, DISCONNETTI, ATTENDI).
• Identità Semantica: Le richieste sono raggruppate per prompt_family_id per consentire a GRIEF di variare il timing e la concorrenza mantenendo fisso il contenuto del prompt, isolando la divergenza del livello di servizio dalla deriva del prompt.

Ciclo di Fuzzing e Mutazioni

GRIEF opera un ciclo greybox che genera, muta ed esegue tracce contro server live, utilizzando feedback runtime (latenza, utilizzo delle risorse, eventi della cache KV) per guidare l'esplorazione. Impiega tre classi di mutazioni a livello di traccia:

1. Mutazioni di Timing: Perturbazione degli offset degli eventi per modificare il co-batching, la sovrapposizione del prefill o il timing di espulsione della cache.
2. Mutazioni di Eventi: Inserimento, eliminazione o modifica degli eventi di ciclo di vita per esercitare percorsi di pulizia, riprova e smantellamento.
3. Mutazioni di Splicing: Combinazione di segmenti da tracce genitore, incluso lo splicing diretto che allinea le fasi di riscaldamento della cache con finestre ad alta pressione per esporre condizioni di gara.

Oracolo e Pipeline di Conferma

Poiché il servizio LLM è rumoroso e parzialmente non deterministico, GRIEF utilizza una pipeline a stadi per distinguere i bug dal rumore infrastrutturale:

1. Oracoli Comportamentali: Rilevano anomalie esterne (ad esempio, regressione severa della latenza, output corrotti, violazioni del ciclo di vita).
2. Conferma Relazionale Assistita da Logprob: Le tracce sospette vengono riprodotte con decodifica deterministica. GRIEF confronta gli output originali e riprodotti. Se divergono, verifica la probabilità logaritmica del primo token divergente. Se il token originale non è un candidato quasi equiparato sotto la distribuzione di riproduzione, conferma una divergenza del livello di servizio (ad esempio, stato KV obsoleto) piuttosto che un'ambiguità di decodifica benigna.
3. Forensics Strutturale KV: Per l'attribuzione ad alta fiducia, GRIEF osserva eventi di ciclo di vita dei blocchi della cache KV fuori banda per rilevare anomalie strutturali come il riutilizzo di blocchi tra adattatori o conflitti hash-contenuto.

Contributi Chiave

1. Identificazione di una Nuova Superficie di Attacco: Il documento identifica l'inferenza concorrente LLM come un confine rilevante per la sicurezza in cui richieste valide possono attivare guasti di isolamento, prestazioni e vivibilità.
2. Sistema GRIEF: La progettazione e l'implementazione di un fuzzer greybox che tratta le tracce temporizzate di più richieste come input, mutando il timing delle richieste, gli eventi di ciclo di vita e i parametri della modalità di servizio.
3. Valutazione Empirica: La valutazione di GRIEF su vLLM e SGLang, scoprendo 15 potenziali vulnerabilità, di cui 10 confermate dagli sviluppatori del motore. Questo include 2 CVE assegnati (ad esempio, CVE-2026-7141) e ulteriori richieste in sospeso.

Risultati e Scoperte

Lo studio categorizza i guasti scoperti in tre classi di impatto:

1. Corruzione dello Stato e Guasti di Isolamento

GRIEF ha scoperto bug in cui l'isolamento della cache KV si rompe, consentendo la contaminazione incrociata dell'output tra richieste.

• Sintomi: "Inquinamento di valori sicuri" (output di un valore errato copiato da un'altra richiesta), "disturbo della catena di ragionamento" (loop infiniti o CoT estesi) e "confusione nel ragionamento risposta-prima" (generazione di una risposta prima del ragionamento).
• Meccanismo: Questi guasti si verificano senza input malformati. La richiesta trigger perturba lo stato di servizio, causando che l'output della vittima sia determinato dalla posizione vulnerabile dello schedulatore piuttosto che dal prompt della vittima da solo.
• Verifica: La riproduzione controllata ha confermato che gli output corrotti erano bit-identici tra diversi prompt trigger, escludendo l'iniezione di prompt e confermando problemi di riutilizzo dello stato.

2. Patologie delle Prestazioni (DoS del Vicino Rumoroso)

GRIEF ha identificato un bug in vLLM in cui una singola forma di richiesta API valida causa un grave interferenza tra richieste.

• Impatto: Il tempo fino al primo token (TTFT) della vittima è aumentato di 1.361× (da ~12ms a ~18s) e il throughput utile è crollato a quasi zero.
• Meccanismo: A differenza del blocco standard in testa alla fila, le tracce eBPF hanno rivelato che il coroutine EngineCore condiviso veniva ripetutamente deschedulato dal sistema operativo. Ciò ha fermato il percorso di guida del motore per tutte le richieste co-schedulate, affamando efficacemente tenant non correlati mentre il server rimaneva vivo e privo di errori.

3. Guasti di Crash e Vivibilità

GRIEF ha trovato carichi di lavoro che violano le invarianti dello schedulatore solo quando le richieste valide sono composte concorrentemente.

• Caso di Studio: Un crash del servizio LoRA di SGLang attivato da una combinazione specifica di alta pressione della cache KV, forme miste di prompt e arrivi esplosivi di adattatori.
• Meccanismo: La visione dello schedulatore degli adattatori attivi divergeva dal set caricato, creando un batch non valido che ha attivato un errore di asserzione. Il crash è stato ritardato, verificandosi dopo un prefill normale e risposte di successo, rendendolo difficile da diagnosticare senza la traccia completa.

Significato e Affermazioni

Il documento sostiene che concorrenza, caching e comportamento dello schedulatore devono essere trattati come confini di sicurezza e affidabilità di prima classe per l'infrastruttura LLM. Le scoperte dimostrano che:

• I test standard di sicurezza del modello e i controlli di conformità API sono insufficienti per proteggere i sistemi di servizio LLM.
• Richieste API valide e documentate possono indurre corruzione silenziosa dell'output, interferenza tra richieste e perdita di disponibilità senza errori espliciti del server.
• Il "livello di servizio" stesso è una superficie di attacco critica in cui i bug possono manifestarsi come anomalie sottili e non di crash invisibili al monitoraggio tradizionale.

Gli autori concludono che l'infrastruttura LLM futura deve integrare il fuzzing del livello di servizio nei processi di test e irrobustimento di routine per mitigare questi rischi prima che si verifichino in produzione. Il lavoro è presentato come un avviso precoce e un cambiamento metodologico verso il trattamento del motore di inferenza come componente critico per la sicurezza, non meramente come substrato di prestazioni.