Foi tempo 37.0.0 e 37.0.1 ter vazamentos de memória na API C/ C++ quando usar as ligações para os valores `anyref` ou `externref` WebAssembly. Isto é causado por uma regressão introduzida durante o desenvolvimento do 37.0.0 e todas as versões anteriores do Wasmtime não são afetadas. Se `anyref` ou `externref` não for usado na API C/C++, as incorporações também não serão afetadas pelo comportamento de vazamento. A caixa de Rust `wasmtime` não é afetada por este vazamento. Desenvolvimento de Wasmtime 37.0.0 Incluiu um refactoring no Rust de mudar o antigo tipo `ManuallyRooted ` para um novo tipo `OwnedRooted `. Esta mudança foi integrada na API C do Wasmtime, mas deixou a API C num estado que tinha vazamentos de memória. Além disso, a nova semântica de propriedade em torno deste tipo não foi refletida na API C++, tornando- a propensa a vazar. Uma versão curta da mudança é que anteriormente `ManuallyRooted `, como o nome indica, chamadas de manual necessárias para uma operação "unroot". Se isto foi esquecido, então a memória ainda estava limpa quando o próprio `wasmtime_store_t` foi destruído eventualmente. A documentação de quando "unroot" estava escassa e já havia situações anteriores 37.0.0 onde a memória seria vazada até a loja ser destruída de qualquer forma. Toda a memória, porém, estava sempre ligada à loja, e destruir a loja garantiria que não havia vazamentos de memória.
Em migrar para o `OwnedRooted ` o uso do tipo em Rust mudou. Uma operação manual "unroot" não é mais necessária e acontece naturalmente como um destrutor do tipo `OwnedRooted ` no próprio Rust. Estes novos recursos semânticos não foram totalmente integrados na semântica pré- existente das APIs C/C++ em Wasmtime. Uma distinção crucial de `OwnedRooted ` vs `ManuallyRooted ` é que o tipo `OwnedRooted ` aloca a memória do hospedeiro fora da loja. Isto significa que se um vazamento de `OwnedRooted ' é vazado, então destruir uma loja não libera esta memória e é um vazamento de memória permanente no hospedeiro. Isto levou a alguns problemas distintos, mas relacionados, que surgiram: * Um tipo de texto na função `wasmtime_val_unroot` na API C significava que ele não desenraizava nada. Isso significava que mesmo que os integradores chamassem fielmente a função, então a memória será vazada. * Se uma função definida pelo host retornasse um valor ` wasmtime_{externref,anyref}_t`, então o valor nunca foi desenraizado. A API C/C++ não tem mais acesso ao valor e a implementação Rust não desarraigou. Isto significa que quaisquer valores retornados desta forma nunca foram desenraizados. * O objetivo da API C++ do Wasmtime é codificar a gestão automática da memória no sistema de tipo, mas a API C++ não foi atualizada quando foi adicionada a ` OwnedRooted '. Isto significava que o uso idiomático da API C++ iria vazar memória devido à falta de destrutores em valores.
Estes problemas foram todos corrigidos em um 37.0.2 lançamento do Wasmtime. A implementação das API C e C++ foi atualizada em conformidade e, respectivamente, para contabilizar as alterações de propriedade aqui. Por exemplo, `wasmtime_val_unroot` foi fixado para desroot, a implementação do lado de Rust de chamar uma função definida por embedder irá desroot de retorno, e a API C++ agora tem destrutores nos tipos `ExternRef`, `AnyRef` e `Val`. Estas alterações foram feitas no 37.0.x liberar ramo de uma forma não- quebra- API. Alterações para o 38.0.0 o ramo de lançamento (e `main` no repositório WSMtime) inclui atualizações menores da API para acomodar melhor as alterações semânticas da API. Foi tempo 37.0.2 foi lançado o que corrige estes problemas. Utilizadores de 37.0.0 e 37.0.1 são recomendados para atualização. Utilizadores de 36.0 O.x e o anterior não são afetados e não precisam atualizar.
A única solução conhecida neste momento é evitar usar `externref` e `anyref` na API C/C++ de Wasmtime. Se não for possível evitar esses tipos, então é necessário que os usuários atualizem para mitigar o problema de vazamento. O projeto WSMtime estará olhando mais de perto para melhorar a situação em torno de testar as APIs C e C++ de WSMtime no futuro próximo. Por exemplo, planejamos integrar testes ASAN para descobrir vazamentos e erros mais cedo no processo de desenvolvimento. Também vamos analisar a expansão da cobertura de teste das APIs C/C++ para captar problemas como este antes no desenvolvimento no futuro.
Registro de aconselhamento: GHSA-vvp 9 - h 8 p 2 -xwfc. Identificadores relacionados: CVE- 2025 - 61670.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 14 T 17: 48: 35.000 Z e lista a sua última modificação como 2026 - 07 - 14 T 17: 48: 35.000 Z.
Severidade: LOW. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L; CVSS_V 4: CVSS: 4.0 /AV:A/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/África do Sul:L.
Informações sobre software e versão afetadas: caixas.io pacote wasmtime-c-api-impl — ECOSYSTEM: introduzido 37.0.0, corrigido 37.0.2. Pacote PyPI wasmtime-bin — ECOSYSTEM: introduzido 0, corrigido 37.0.2.
Classificação e evidência: identificadores de fraqueza CWE- 772. O registro contém 6 suporte de referências nestes tipos: WEB, AVISO, EMBALAGAMENTO.