Bugs de incorreção encontrados há 11 anos no borrow checker do Rust

Artigo original ↗ Discussão no Hacker News ↗

Foi encontrado um bug de soundness de 11 anos no borrow checker do Rust, em que código aparentemente normal envolvendo lifetimes e uma implementação personalizada de `Drop` é aceito incorretamente, permitindo que uma referência sobreviva aos dados a que aponta. Comentadores explicam como isso viola a promessa central de segurança de memória do Rust, enfatizam que se trata de um erro de implementação do compilador e não de uma falha no sistema de tipos da linguagem, e observam que parece exigir um destrutor artificial para virar um exploit real. O incidente alimenta um debate mais amplo sobre o quão “seguro” o Rust realmente é em comparação com C, os limites de qualquer sistema de tipos ou prova formal, e o papel crescente de ferramentas (incluindo IA) na descoberta de bugs sutis em compiladores.

Natureza do bug

  • Incorreção no borrow checker em torno de T: 'static e Drop.
  • Exemplo mínimo: uma struct genérica Q<T: 'static>(Option<T>) com uma implementação de Drop também limitada por 'static.
  • O compilador permite erroneamente armazenar uma referência não‑'static (por exemplo, &l com tempo de vida de stack) em Q, que supostamente deve conter apenas dados 'static.
  • O destrutor então pode tratar isso como 'static, por exemplo, guardando-o em uma variável global, permitindo use-after-free.

Por que isso passou despercebido

  • O padrão que dispara o problema é considerado incomum: precisa de um Drop personalizado mais limites de lifetime em uma configuração específica.
  • Há debate sobre quão “normal” é usar Drop personalizado: alguns dizem que é raro, outros que é comum, especialmente com FFI; mas esse padrão exato é raro.
  • Muitos programas com lifetime inválido podem nunca falhar visivelmente, então o bug poderia ser acionado sem uma falha óbvia.

Garantias de segurança, soundness e UB

  • Esclarecimento:
    • Incorreção = Rust seguro pode causar UB por causa de bugs no compilador/type checker.
    • UB na especificação = o usuário saiu do comportamento bem definido.
  • O bug está no compilador, não nas regras de lifetime pretendidas do Rust; a correção é rejeitar esse código.
  • Alguns observam que há muitos problemas abertos de incorreção; outros enfatizam que as correções podem ser lançadas até em releases de patch, e o código afetado nunca foi “Rust válido”.

Comparações com C e outras linguagens

  • Alguns usam isso para argumentar que o marketing de segurança do Rust é exagerado ou dá uma falsa sensação de segurança.
  • Outros contrapõem que C/C++ também têm bugs de compilador além de UB disseminado no nível da linguagem, então o Rust ainda representa uma grande melhoria de segurança.
  • Há discussão de que nenhuma linguagem pode ser perfeitamente segura; o objetivo é tornar classes de bugs impossíveis ou extremamente raras.

Métodos formais e IA

  • Referências a esforços em andamento para especificar formalmente ou provar o Rust ou subconjuntos dele.
  • Reconhecimento de que até assistentes de prova, especificações e a matemática subjacente podem estar errados, então garantias absolutas são impossíveis.
  • Alguns veem IA/LLMs como ferramentas promissoras para fuzzing/busca de bugs como este em compiladores; outros são céticos ou estão cansados do hype de IA.

Dinâmica da comunidade e social

  • Reclamações sobre evangelismo do Rust e percepção de ataques a outras linguagens versus defesas de que a comunicação oficial é mais moderada.
  • Meta-discussão sobre reações exageradas a bugs individuais: alguns pedem perspectiva—este é um defeito real, porém estreito, não um fracasso total do modelo do Rust.