LLMs falham em Rust inseguro: seis meses de testes revelam erros críticos

O autor pediu a LLMs que escrevessem código unsafe Rust em projetos de produção por seis meses e verificou cada bloco com o Miri e sanitizers. O resultado foi decepcionante: os modelos cometem os mesmos erros de forma previsível e consistente.

Sete categorias de erros de LLMs em unsafe Rust

Os modelos erram sempre nos mesmos pontos:

• Aliasing — violação da regra sobre referências que não se sobrepõem
• Provenance — tentativas de usar ponteiros obtidos de forma incorreta
• Layout em alloc/dealloc — incompatibilidade de tamanho e alinhamento entre a alocação e a liberação
• ManuallyDrop — esquecem de chamar drop ou usam o objeto depois do drop
• Corridas em callbacks de FFI — condições de corrida ao chamar funções C a partir de threads
• Send/Sync manuais — implementam incorretamente as traits de segurança entre threads
• Memória não inicializada — tratam dados não inicializados como se estivessem inicializados

Por que o Miri expôs os problemas

O Miri é um interpretador de Rust que rastreia comportamento indefinido. Quando um LLM gera código com violações pouco óbvias à primeira vista (por exemplo, um ponteiro temporário com procedência incorreta), o compilador comum deixa passar, mas o Miri pega. Com os sanitizers (AddressSanitizer, ThreadSanitizer), vieram à tona corridas e bugs de use-after-free que podem não aparecer em testes comuns.

"Cada categoria vem com um exemplo mínimo e uma correção" — o autor

mostra que não são meras observações, mas padrões de erro reproduzíveis.

O que isso significa

Os LLMs ainda não estão prontos para escrever unsafe Rust sem supervisão humana. Eles geram bem a sintaxe e a lógica geral, mas erram sistematicamente no trabalho com memória e multithreading. Para código crítico (software de sistema, bibliotecas de sistema), o unsafe Rust escrito por modelos precisa obrigatoriamente ser verificado no Miri.