Riscrittura di Bun in Rust: Miri rivela codice non sicuro, scatena dibattito sulla sicurezza

Una violazione della sicurezza fondamentale nella porta Rust di Bun

È stata esposta una significativa falla di sicurezza nella riscrittura in corso di Bun, il runtime JavaScript ad alte prestazioni, in Rust. Un problema su GitHub segnalato il 14 maggio 2026, dimostra che il codebase "fallisce anche i controlli Miri più basilari" e "consente UB [comportamento indefinito] in Rust sicuro". Il problema include un caso di riproduzione minimale che causa a Miri, il controllore ufficiale di comportamento indefinito di Rust, di segnalare un errore di riferimento penzolante.

Il problema principale risiede nella funzione PathString::init. Questa funzione sicura accetta un riferimento a una slice di byte (&[u8]) ma internamente utilizza codice non sicuro per memorizzare un puntatore grezzo, cancellando effettivamente la durata di vita dell'input. Ciò consente al tipo PathString restituito, che è 'static, di sopravvivere ai dati a cui punta, portando a scenari di uso dopo il rilascio. Come ha spiegato il commentatore JavaDerg, questo "cancella la durata di vita e restituisce Self che è 'static. Questo è incredibilmente cattivo perché consente l'uso dopo il rilascio, aliasing non valido, ecc.".

Ulteriori analisi del reporter, AwesomeQubic, hanno notato che il codice "cancella anche la provenienza" e fallisce sotto i controlli di provenienza rigorosi di Miri. Un collaboratore di Bun, robobun, ha confermato il problema e ha inviato una richiesta di pull (#30728) contrassegnando le funzioni problematiche come unsafe e controllando circa 70 siti di chiamata nel codebase. La correzione blocca la regressione con un test per garantire che le firme rimangano non sicure.

Il contesto più ampio del codebase e la reazione della comunità

Questo incidente non è isolato. Dopo la segnalazione iniziale, GitHub Actions ha automaticamente fatto riferimento a diverse altre richieste di pull che affrontano modelli di codice non sicuri simili nel repository di Bun. Queste includono sostituzioni per blocchi non sicuri in ArrayHashMap (#30723), correzioni di bug di sicurezza nel trait LinearFifo (#30724) e una riscrittura sicura di DynamicBitSet (#30730). Ciò suggerisce che la traduzione iniziale in Rust ha introdotto problemi sistematici con la gestione del codice non sicuro.

La reazione della comunità è stata rapida e critica. Molti commentatori hanno collegato i problemi direttamente all'uso ammesso dal progetto di AI, in particolare Claude di Anthropic, per la maggior parte della riscrittura. Un utente, mikuwithbeer, ha affermato che il progetto era diventato "un puro slop di AI", criticando la priorità data alla dimostrazione delle capacità di AI rispetto all'assunzione di sviluppatori esperti di Rust. Il sentimento è stato ribadito da altri che hanno sostenuto che le garanzie di sicurezza di Rust sono annullate da tali astrazioni non sicure, creando potenzialmente scenari "ben peggiori di quelli tipici nel codice C/C++".

Tuttavia, alcuni hanno difeso lo sforzo. L'utente Warchamp7 lo ha inquadrato come "il coraggio di costruire, fallire e imparare in pubblico", incoraggiando il team a continuare a risolvere i problemi. Il fondatore del progetto, Jarred Sumner, ha successivamente indicato sui social media che stanno cercando di assumere qualcuno con esperienza in Rust.

Analisi tecnica: i pericoli di ignorare le durate di vita e la provenienza

L'errore fondamentale in PathString::init rappresenta un classico malinteso del sistema di proprietà di Rust. Quando un tipo detiene un puntatore a dati che non possiede, deve tracciare esplicitamente la durata di vita di quei dati utilizzando parametri generici e spesso marcatori PhantomData. Come ha spiegato TehPers, "L'apprendimento a basso livello qui è che le durate di vita non possono essere ignorate". L'apprendimento ad alto livello è che "tutto il codice non sicuro dovrebbe essere esaminato molto da vicino da qualcuno esperto nella scrittura di Rust".

Questo incidente evidenzia una lacuna critica nella traduzione del codice assistita da AI. Le LLM come Claude possono generare Rust sintatticamente corretto che compila ma può violare completamente le regole di sicurezza semantica del linguaggio, specialmente intorno alle durate di vita, al prestito e agli invarianti dei blocchi non sicuri. Il codice risultante può essere sottilmente e catastroficamente rotto, introducendo vulnerabilità di corruzione della memoria che Rust è esplicitamente progettato per prevenire.

La situazione traccia un netto contrasto con altre migrazioni linguistiche attente, come la riscrittura manuale di Andreas Kling dei componenti del motore JavaScript di Ladybird da C++ a Rust in due settimane, che ha prodotto 30k righe di codice controllato.

Un racconto ammonitore in un panorama di sicurezza più ampio

Questa scoperta arriva in un momento di maggiore consapevolezza della sicurezza del software fondamentale. La fonte 2 (Dark Reading) discute come il codice generato da AI introduce nuovi rischi imprevedibili, costringendo i difensori ad adattarsi. Il caso di Bun è un esempio concreto di tale codice "noioso" ma pericoloso - funzioni di utilità apparentemente banali che diventano passività di sicurezza.

Simultaneamente, l'industria sta lottando con vulnerabilità a lungo termine nell'infrastruttura critica. La fonte 3 descrive CVE-2026-42945, un overflow del buffer heap di 18 anni nel modulo di riscrittura di NGINX che interessa le versioni a partire dalla 0.6.27. Come il problema di Bun, deriva da una gestione dello stato incoerente - nel caso di NGINX, tra il calcolo della dimensione del buffer e le passate di scrittura dei dati. Questo difetto, presente in un terzo dei principali siti web, sottolinea come errori di logica sottili possano persistere per decenni.

Inoltre, le fonti 4 e 5 riferiscono su "Dirty Frag" (CVE-2026-43284 e CVE-2026-43500), una nuova vulnerabilità di escalation dei privilegi nel kernel Linux simile a Dirty Pipe. Con un exploit di prova di concetto pubblico disponibile, dimostra la pressione costante sulla sicurezza dei sistemi core. Queste storie parallele enfatizzano che la sicurezza è un processo continuo di revisione e patching rigorosi, sia per un server web di 18 anni che per un codebase appena generato da AI.

Conclusione: la strada da seguire per Bun e lo sviluppo assistito da AI

La saga della riscrittura di Bun in Rust presenta una lezione multiforme. In primo luogo, convalida l'importanza di strumenti come Miri per progetti che utilizzano Rust non sicuro. In secondo luogo, serve come un avvertimento chiaro sui limiti dell'AI attuale in compiti di codifica complessi e critici per la sicurezza. L'AI può essere un assistente potente, ma non può sostituire una profonda esperienza nel dominio, specialmente per la programmazione dei sistemi.

La risposta del progetto - riconoscere il bug, applicare correzioni e cercare aiuto esperto - è un passo positivo. Tuttavia, la portata degli audit necessari suggerisce che la riscrittura potrebbe aver accumulato un significativo debito tecnico. La prova definitiva sarà se il team di Bun potrà esaminare e proteggere sistematicamente l'intero codebase tradotto, trasformandolo da una prova di concetto in un sistema robusto e pronto per la produzione. Per l'industria più ampia, questo episodio è un caso di studio sui rischi e le responsabilità dell'adozione della generazione di codice AI per componenti software fondamentali.