Technische Samenvatting: Continue Ontdekking van Kwetsbaarheden in LLM-Serving Systemen met Fuzzing

Probleemstelling

Systemen voor inferentie en serving van Large Language Models (LLM) (bijv. vLLM, SGLang) zijn uitgegroeid tot kritieke infrastructuur voor moderne AI-toepassingen. Deze systemen maken gebruik van agressieve optimalisaties zoals KV-caching, dynamische batching, prefix-sharing, speculatieve decoding en multi-tenant scheduling om de reken- en geheugeneisen van grote modellen te beheersen. Deze complexiteit creëert echter een distinct en ondergetest kwetsbaarheidsoppervlak binnen de servinglaag.

Huidige veiligheidstests richten zich voornamelijk op modelgedrag (bijv. jailbreaks, hallucinaties) of individuele API-compliance. Deze benaderingen slagen er niet in om fouten te vangen die voortvloeien uit de software-uitvoeringslogica van geldige inferentieverzoeken wanneer deze worden verwerkt onder realistische, gelijktijdige werklasten. Recent empirisch onderzoek geeft aan dat meer dan 35% van de bugs in deze systemen zich manifesteert als niet-crash anomalieën in plaats van directe crashes. Specifiek kunnen fouten in de serving-stack leiden tot:

• Stille staatcorruptie: Kruisverontreiniging van verzoeken waarbij de output van één verzoek wordt gecorrumpeerd door de cache-status van een ander.
• Prestatiepathologieën: "Noisy-neighbor" denial of service waarbij geldige verzoeken leiden tot ernstige latentieversterking of instorting van de doorvoer voor ongerelateerde tenants, zonder dat de server crasht.
• Vertraagde beschikbaarheidsfouten: Crashes die pas worden geactiveerd door de specifieke gelijktijdige samenstelling van geldige verzoeken, waardoor scheduler-invarianten worden geschonden.

Bestaande testmethoden (modelniveau-evaluaties, standaard API-tests en conventionele fuzzers) oefenen de timing, overlapping en gedeelde-staatinteracties niet systematisch uit die bepalen of een serving-systeem isolatie behoudt.

Methodologie: GRIEF

Om deze kloof aan te pakken, presenteren de auteurs GRIEF (GReybox Inference Engine Fuzzer), een greybox fuzzer die specifiek is ontworpen voor LLM-inferentie- en serving-systemen.

Kernabstractie: Getimede Verzoeksporen

In tegenstelling tot traditionele fuzzers die byte-strings of geïsoleerde prompts muteren, behandelt GRIEF getimede multi-verzoeksporen als first-class inputs. Een spoor is een reeks tijdstempelde client-side gebeurtenissen die vastleggen:

• Verzoekinhoud: De prompt en parameters.
• Schedulingsstructuur: Wanneer verzoeken overlappen, hoe ze concurreren om gedeelde staat, en hun levenscyclusgebeurtenissen (SEND, CANCEL, DISCONNECT, WAIT).
• Semantische Identiteit: Verzoeken worden gegroepeerd op basis van prompt_family_id om GRIEF toe te staan timing en concurrentie te variëren terwijl de promptinhoud constant blijft, waardoor divergentie op serving-niveau wordt geïsoleerd van prompt-drift.

Fuzzing-lus en Mutaties

GRIEF voert een greybox-lus uit die sporen genereert, muteert en uitvoert tegen live servers, waarbij runtime-feedback (latentie, resourcegebruik, KV-cache-gebeurtenissen) wordt gebruikt om de verkenning te sturen. Het maakt gebruik van drie klassen van mutaties op sporniveau:

1. Timing-mutaties: Het verstoren van gebeurtenis-offsets om co-batching, prefill-overlapping of cache-evictietiming te veranderen.
2. Gebeurtenismutaties: Het invoegen, verwijderen of wijzigen van levenscyclusgebeurtenissen om opschonings-, herstel- en afbraakpaden te oefenen.
3. Splicing-mutaties: Het combineren van segmenten uit ouder-spoor, inclusief gerichte splicing die cache-opwarmingsfasen aligneert met periodes van hoge druk om race-omstandigheden bloot te leggen.

Oracle en Bevestigingspijplijn

Omdat LLM-serving luidruchtig en gedeeltelijk niet-deterministisch is, gebruikt GRIEF een gefaseerde pijplijn om bugs te onderscheiden van infrastructuurlawaai:

1. Gedragsorakels: Detecteren van externe anomalieën (bijv. ernstige latentieretrogressie, gecorrumpeerde outputs, levenscyclusschendingen).
2. Logprob-ondersteunde relationele bevestiging: Verdachte sporen worden opnieuw afgespeeld met deterministische decoding. GRIEF vergelijkt de originele en opnieuw afgespeelde outputs. Als deze divergeren, controleert het de log-probabiliteit van het eerste afwijkende token. Als het originele token geen bijna-gelijkwaardige kandidaat is onder de opnieuw afgespeelde verdeling, bevestigt dit een divergentie op serving-niveau (bijv. verouderde KV-status) in plaats van een onschadelijke decoding-ambiguïteit.
3. Structurele KV-forensiek: Voor toewijzing met hoge zekerheid observeert GRIEF out-of-band KV-cache-bloklevenscyclusgebeurtenissen om structurele anomalieën te detecteren, zoals hergebruik van blokken tussen adapters of hash-inhoudconflicten.

Belangrijkste Bijdragen

1. Identificatie van een nieuw aanvalsoppervlak: Het paper identificeert gelijktijdige LLM-inferentie-serving als een veiligheidsrelevante grens waar geldige verzoeken isolatie-, prestatie- en beschikbaarheidsfouten kunnen activeren.
2. GRIEF-systeem: Het ontwerp en de implementatie van een greybox fuzzer die getimede multi-verzoeksporen als inputs behandelt, waarbij verzoektiming, levenscyclusgebeurtenissen en serving-modusparameters worden gemuteerd.
3. Empirische evaluatie: De evaluatie van GRIEF op vLLM en SGLang, waarbij 15 potentiële kwetsbaarheden werden ontdekt, waarvan er 10 door engine-ontwikkelaars werden bevestigd. Dit omvat 2 toegewezen CVE's (bijv. CVE-2026-7141) en aanvullende aanhangige verzoeken.

Resultaten en Bevindingen

De studie categoriseert ontdekte fouten in drie impactklassen:

1. Staatcorruptie en Isolatiefouten

GRIEF ontdekte bugs waarbij KV-cache-isolatie faalt, waardoor kruisverontreiniging van verzoekoutput mogelijk wordt.

• Symptomen: "Zekerheidswaarde-verontreiniging" (het uitvoeren van een verkeerde waarde die is gekopieerd van een ander verzoek), "redeneerketenverstoring" (oneindige lussen of uitgebreide CoT) en "antwoord-eerst-redeneringsverwarring" (het genereren van een antwoord voordat er wordt geredeneerd).
• Mechanisme: Deze fouten treden op zonder misvormde inputs. Het trigger-verzoek verstoort de serving-status, waardoor de output van het slachtoffer wordt bepaald door de kwetsbare schedulingspositie in plaats van alleen door de prompt van het slachtoffer.
• Verificatie: Gecontroleerd opnieuw afspelen bevestigde dat gecorrumpeerde outputs bit-identiek waren over verschillende trigger-prompts, waardoor prompt-injectie werd uitgesloten en staatshergebruikproblemen werden bevestigd.

2. Prestatiepathologieën (Noisy-neighbor DoS)

GRIEF identificeerde een bug in vLLM waarbij een enkele API-geldige verzoekvorm ernstige kruisverontreiniging tussen verzoeken veroorzaakt.

• Impact: De time-to-first-token (TTFT) van het slachtoffer nam toe met 1.361× (van ~12ms naar ~18s), en de nuttige doorvoer stortte in tot bijna nul.
• Mechanisme: In tegenstelling tot standaard head-of-line blocking, onthulden eBPF-traces dat de gedeelde EngineCore-coroutine herhaaldelijk door het OS werd gedescheduld. Dit hield het engine-aandrijfpad voor alle gezamenlijk geplande verzoeken stil, waardoor ongerelateerde tenants effectief werden uitgehongerd terwijl de server levend en foutloos bleef.

3. Crash- en Beschikbaarheidsfouten

GRIEF vond werklasten die scheduler-invarianten schenden, maar alleen wanneer geldige verzoeken gelijktijdig worden samengesteld.

• Casestudie: Een crash in SGLang LoRA-serving, geactiveerd door een specifieke combinatie van hoge KV-cache-druk, gemengde promptvormen en bursty adapter-aankomsten.
• Mechanisme: Het perspectief van de scheduler op actieve adapters divergeerde van de geladen set, waardoor een ongeldige batch ontstond die een assertiefout activeerde. De crash was vertraagd en trad op na normale prefill en succesvolle antwoorden, wat het moeilijk maakte te diagnosticeren zonder het volledige spoor.

Betekenis en Aanspraken

Het paper betoogt dat concurrentie, caching en scheduler-gedrag als first-class veiligheids- en betrouwbaarheidsgrenzen moeten worden behandeld voor LLM-infrastructuur. De bevindingen tonen aan dat:

• Standaard modelveiligheidstests en API-compliancechecks ontoereikend zijn voor het beveiligen van LLM-serving-systemen.
• Geldige, gedocumenteerde API-verzoeken stille outputcorruptie, kruisverontreiniging tussen verzoeken en verlies van beschikbaarheid kunnen veroorzaken zonder expliciete serverfouten.
• De "servinglaag" zelf een kritiek aanvalsoppervlak is waar bugs zich kunnen manifesteren als subtiele, niet-crash anomalieën die onzichtbaar zijn voor traditionele monitoring.

De auteurs concluderen dat toekomstige LLM-infrastructuur fuzzing op serving-niveau moet integreren in routine-test- en versterkingsprocessen om deze risico's te mitigeren voordat ze in productie worden aangetroffen. Het werk wordt gepresenteerd als een vroegtijdige waarschuwing en een methodologische verschuiving richting het behandelen van de inferentie-engine als een veiligheidskritisch onderdeel, en niet slechts als een performance-substraat.