Alexcrichton

**Nome do Software Vulnerável e Versões Afetadas** Wasmtime versões anteriores a 36.0.8 Wasmtime versões anteriores a 43.0.2 Wasmtime versões anteriores a 44.0.1 **Description** A lógica de alocação para uma tabela WebAssembly contém aritmética verificada que entra em pânico (panic) em caso de estouro (overflow) quando uma tabela de tamanho extremamente grande é alocada. Isso ocorre durante a instanciação de um módulo ou componente WebAssembly e é possível quando o recurso WebAssembly `memory64` está habilitado, permitindo tamanhos de tabela na faixa de 64 bits. O problema afeta especificamente o alocador de instâncias sob demanda, que é o alocador padrão, e pode levar a uma negação de serviço ao causar o pânico do processo hospedeiro. **Recommendations** Atualizar para a versão 36.0.8. Atualizar para a versão 43.0.2. Atualizar para a versão 44.0.1. Mudar para o uso do alocador de pooling. Desativar a proposta WebAssembly `memory64`.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Wasmtime 39.0.0 a 41.0.3 **Descrição** O Wasmtime, um runtime para WebAssembly, pode sofrer um panic quando o embedder do host descarta o future retornado por `wasmtime::component::[Typed]Func::call async` antes de sua resolução e, em seguida, chama a mesma função novamente com a mesma instância de componente. Isso ocorre porque a instância do componente entra em um estado não reentrável, levando a um trap e subsequente panic durante o descarte da tarefa. O problema surge de um bug na implementação de `[Typed]Func::call async` introduzido com a feature `component-model-async`, que se tornou o padrão a partir da versão 39.0.0. O `Endpoint da API` envolvido é `wasmtime::component::[Typed]Func::call async`. A `variável` representando o future retornado não é nomeada explicitamente, mas seu manejo inadequado dispara o problema. O problema não afeta incorporações com a feature de tempo de compilação `component-model-async` desativada. **Recomendações** As versões do Wasmtime 39.0.0 a 40.0.3 devem ser atualizadas para a versão 40.0.4 ou 41.0.4. As versões do Wasmtime 40.0.4 a 41.0.3 devem ser atualizadas para a versão 41.0.4. Se uma incorporação não estiver usando nenhuma funcionalidade component-model-async, desative a feature do Cargo `component-model-async`. Garanta que cada future `call async` seja aguardado até sua conclusão. Evite usar o `Store` novamente após descartar um future `call async` ainda não resolvido.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Wasmtime anteriores a 24.0.6 Versões do Wasmtime anteriores a 36.0.6 Versão do Wasmtime 4.0.04 Versões do Wasmtime anteriores a 41.0.4 Versões do Wasmtime anteriores a 42.0.0 **Descrição** A implementação do recurso `wasi:http/types.fields` do Wasmtime é suscetível a pânico quando um número excessivo de campos é adicionado ao conjunto de cabeçalhos. O crate `wasmtime-wasi-http` utiliza uma estrutura de dados que entra em pânico quando atinge sua capacidade, e essa condição não foi tratada adequadamente. Um pânico em uma implementação WASI pode levar a uma Negação de Serviço para os incorporadores. **Recomendações** Atualize para a versão 24.0.6 ou posterior do Wasmtime. Atualize para a versão 36.0.6 ou posterior do Wasmtime. Atualize para a versão 4.0.04 ou posterior do Wasmtime. Atualize para a versão 41.0.4 ou posterior do Wasmtime. Atualize para a versão 42.0.0 ou posterior do Wasmtime.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Wasmtime 37.0.0 a 37.0.1 **Descrição** O Wasmtime, um runtime para WebAssembly, contém vazamentos de memória em sua API C/C++ ao utilizar bindings para valores WebAssembly `anyref` ou `externref`. Este problema decorre de uma regressão introduzida durante o desenvolvimento da versão 37.0.0, especificamente relacionada a uma refatoração de `ManuallyRooted<T>` para `OwnedRooted<T>` em Rust. As APIs C e C++ não foram totalmente atualizadas para refletir as novas semânticas de propriedade de `OwnedRooted<T>`, levando a vazamentos de memória. Especificamente, um erro de digitação na função `wasmtime val unroot` impediu o desenraizamento adequado, e funções definidas pelo host que retornam valores `wasmtime {externref,anyref} t` nunca tiveram suas raízes removidas. A API C++ carecia de destrutores em tipos relevantes, contribuindo ainda mais para o problema. Esses vazamentos ocorrem quando `anyref` ou `externref` são usados na API C/C++, e o crate Rust `wasmtime` não é afetado. **Recomendações** Atualize para a versão 37.0.2 ou posterior do Wasmtime para corrigir os vazamentos de memória na API C/C++. Evite usar `externref` e `anyref` na API C/C++ do Wasmtime se a atualização não for imediatamente possível.

**Nome do software vulnerável e versões afetadas** Versões do Wasmtime 21.0.0 a 21.0.1 Versões do Wasmtime 22.0.0 a 22.0.0 Versões do Wasmtime 23.0.0 a 23.0.2 Versões do Wasmtime 24.0.0 a 24.0.0 Versões do Wasmtime 25.0.0 a 25.0.1 **Descrição** O problema está relacionado à implementação do Wasmtime de chamadas de cauda do WebAssembly combinadas com rastreamentos de pilha, o que pode resultar em uma falha de tempo de execução em determinados módulos do WebAssembly. Isso pode ocorrer quando uma função exportada em um módulo do WebAssembly executa um `return call` (ou `return call indirect` ou `return call ref`) para uma função host importada que captura um rastreamento de pilha. A falha é causada por uma assertiva interna no código de rastreamento de pilha que gera um `panic!()` do Rust. O impacto desse problema é um vetor de negação de serviço, no qual um módulo ou componente WebAssembly malicioso pode causar a falha do host. Não há outro impacto no momento além da disponibilidade do serviço, já que o resultado da falha é sempre uma falha e nada mais. **Recomendações** Para as versões 21.0.0 a 21.0.1 do Wasmtime, atualize para a versão 21.0.2. Para as versões 22.0.0 a 22.0.0 do Wasmtime, atualize para a versão 22.0.1. Para as versões 23.0.0 a 23.0.2 do Wasmtime, atualize para a versão 23.0.3. Para as versões 24.0.0 a 24.0.0 do Wasmtime, atualize para a versão 24.0.1. Para as versões 25.0.0 a 25.0.1 do Wasmtime, atualize para a versão 25.0.2. Como solução alternativa temporária, considere desativar o suporte a chamadas de cauda no Wasmtime definindo `Config::wasm tail call(

**Name of the Vulnerable Software and Affected Versions** wasmtime versions prior to 4.0.1 wasmtime versions prior to 5.0.1 wasmtime versions prior to 6.0.1 **Description** The issue is related to a bug in the Cranelift code generator of wasmtime, which mistakenly calculates a 35-bit effective address instead of the defined 33-bit effective address for WebAssembly. This allows a malicious module to read or write memory up to 34G away from the base of linear memory, potentially leading to arbitrary code execution or data corruption. The bug is specific to x86 64 targets and does not affect the AArch64 backend. Affected embedders are recommended to analyze preexisting wasm modules for potential exploitation and consider workarounds to mitigate the issue. **Recommendations** For wasmtime versions prior to 4.0.1: Update to version 4.0.1 or later to fix the erroneous lowering rules in the Cranelift backend. For wasmtime versions prior to 5.0.1: Update to version 5.0.1 or later to fix the erroneous lowering rules in the Cranelift backend. For wasmtime versions prior to 6.0.1: Update to version 6.0.1 or later to fix the erroneous lowering rules in the Cranelift backend. As a temporary workaround, consider using the `Config::static memory maximum size(0)` option to force explicit bounds checking for all accesses to linear memory. Alternatively, use the `Config::static memory guard size(1 << 36)` option to increase the guard pages placed after linear memory, or switch to a non-x86 64 host if possible.

**Nome do software vulnerável e versões afetadas** Versões do Wasmtime anteriores à 2.0.2 **Descrição** Existe um bug na implementação da API C do Wasmtime, em que a definição de `wasmtime trap code` não corresponde à sua assinatura declarada no arquivo de cabeçalho `wasmtime/trap.h`. Essa discrepância faz com que a implementação da função execute uma gravação de 4 bytes em um buffer de 1 byte fornecido pelo chamador, levando à gravação de três bytes nulos além do local de 1 byte fornecido pelo chamador. Esse problema afeta usuários da função da API C `wasmtime trap code`, mas não usuários do crate `wasmtime`. **Recomendações** Para versões anteriores à 2.0.2, atualize para o Wasmtime 2.0.2 para resolver o problema. Como solução alternativa temporária, considere fornecer um buffer de 4 bytes convertido para um buffer de 1 byte ao chamar `wasmtime trap code`.

**Nome do software vulnerável e versões afetadas** Versões do Wasmtime anteriores à 2.0.2 **Descrição** Existe um bug na implementação do alocador de instâncias em pool do Wasmtime, pelo qual, quando uma memória linear é reutilizada para outra instância, o instantâneo inicial da pilha da instância anterior pode ficar visível, erroneamente, para a instância seguinte. Esse bug ocorre quando um slot no alocador de pooling foi usado anteriormente para um módulo com uma imagem de heap, e a instância seguinte dentro desse slot não contém, por si só, uma imagem de heap. É altamente improvável que o bug seja acionado acidentalmente e, de outra forma, exigiria um acionamento intencional com um módulo criado manualmente. Na prática, os módulos devem ser deliberadamente criados para não terem uma imagem de heap inicial, a fim de visualizar o conteúdo de uma imagem anterior. **Recomendações** Para resolver o problema, atualize para o Wasmtime 2.0.2. Como solução alternativa temporária, considere desativar o alocador de pool. Além disso, desativar o recurso `memory-init-cow` pode mitigar o problema.

**Nome do software vulnerável e versões afetadas** Versões do Wasmtime anteriores à 2.0.2 **Descrição** Existe um bug na implementação do alocador de instâncias em pool do Wasmtime quando o alocador é configurado para atribuir às instâncias do WebAssembly um máximo de zero páginas de memória. Nessa configuração, o mapeamento de memória virtual para as memórias do WebAssembly não atendia aos requisitos de configuração exigidos pelo compilador para a execução segura de módulos do WebAssembly. As configurações padrão do Wasmtime exigem que falhas de página de memória virtual indiquem que as leituras/gravações do wasm estão fora dos limites, mas a configuração do alocador de pool não criaria um mapeamento de memória virtual apropriado para isso, o que significa que leituras/gravações fora dos limites podem ler/gravar com sucesso memória não relacionada à sandbox do wasm dentro do intervalo do endereço base do mapeamento de memória criado pelo alocador de pool. Este bug só pode ser acionado definindo `InstanceLimits::memory pages` como zero. Espera-se que essa seja uma configuração muito rara, já que isso significa que os módulos Wasm não podem alocar nenhuma página de memória linear. É altamente provável que todos os módulos Wasm produzidos por todas as cadeias de ferramentas atuais utilizem memória linear; portanto, é improvável que essa configuração seja definida como zero em qualquer incorporação do Wasmtime em produção. **Recomendações** Para resolver o problema, atualize para o Wasmtime 2.0.2. Como solução alternativa temporária, considere aumentar a alocação de `memory pages` ao configurar o alocador de pool para um valor maior que

**Nome do software vulnerável e versões afetadas** Versões do Wasmtime 0.37.0 a 0.38.1 **Descrição** Existe um bug no gerador de código do Wasmtime, o Cranelift, em que funções que utilizam tipos de referência podem estar incorretamente sem os metadados necessários para a coleta de lixo em tempo de execução. Isso significa que, se ocorrer uma coleta de lixo em tempo de execução, a passagem de coleta de lixo irá erroneamente considerar que essas funções não possuem referências ativas a valores coletados, recuperando-os e desalocando-os. A função continuará então a usar os valores, assumindo que eles não foram recolhidos, levando posteriormente a um uso após liberação (use-after-free). Esse bug foi introduzido na migração para o alocador de registros `regalloc2`, que ocorreu na versão 0.37.0 do Wasmtime. **Recomendações** Para resolver o problema, atualize para a versão 0.38.2 do Wasmtime. Como solução temporária, considere desativar a proposta de tipos de referência passando `false` para `wasmtime::Config::wasm reference types`. Como alternativa, faça o downgrade para o Wasmtime 0.36.0 ou anterior.

**Nome do software vulnerável e versões afetadas** Versões do Wasmtime anteriores à 0.38.1 Versões do cranelift-codegen anteriores à 0.85.1 **Descrição** O problema está relacionado à implementação do Wasmtime da proposta SIMD para WebAssembly em x86 64, que continha dois bugs nas conversões de instruções implementadas no Cranelift. Os bugs estavam presentes nas instruções WebAssembly `i8x16.swizzle` e `select`. A instrução `select` é afetada apenas quando as entradas são do tipo `v128`. As instruções do Cranelift afetadas correspondentemente foram `swizzle` e `select`. Esse bug representa uma implementação incorreta da semântica especificada dessas instruções de acordo com a especificação do WebAssembly. O impacto disso é benigno para hosts que executam WebAssembly, mas representa possíveis vulnerabilidades na execução de um programa convidado. Por exemplo, um programa WebAssembly poderia tomar ramificações indesejadas ou materializar valores incorretos internamente, o que corre o risco de expor o próprio programa a outras vulnerabilidades relacionadas que podem ocorrer devido a compilações incorretas. **Recomendações** Para versões do Wasmtime anteriores à 0.38.1, atualize para a versão 0.38.1 ou posterior. Para versões do cranelift-codegen anteriores à 0.85.1, atualize para a versão 0.85.1 ou posterior. Como solução alternativa temporária, considere desativar a proposta Wasm simd definindo `config.wasm simd(false)`.

**Nome do software vulnerável e versões afetadas** Versões do Wasmtime anteriores à 0.30.0 **Descrição** Foi descoberta uma vulnerabilidade de confusão de tipos na API segura das APIs `Linker::func *`. Esse problema ocorre quando um `Engine` é usado para criar o `Linker`, depois um `Engine` diferente é usado para criar um `Store` e, em seguida, o `Linker` é usado para instanciar um módulo nesse `Store`. O uso de funções entre `Engines` diferentes não é suportado no Wasmtime, o que pode resultar em confusão de tipos de ponteiros de função, permitindo que uma função seja chamada com segurança com o tipo errado. Além disso, havia um bug de liberação inválida e leitura e gravação fora dos limites ao executar Wasm que usa `externref`s no Wasmtime. Espera-se que o impacto desses problemas seja relativamente pequeno, pois o uso de mais de um `Engine` em uma incorporação e o uso de `externref` são atualmente bastante raros. **Recomendações** Para resolver o problema, atualize para a versão 0.30.0 do Wasmtime. Se você não puder atualizar o Wasmtime e estiver usando mais de um `Engine` em sua incorporação, use apenas um `Engine` para todo o programa, se possível. Se for necessário usar vários `Engine`s, audite o código para garantir que o `Linker` seja usado apenas com um `Engine`. Se você não puder atualizar o Wasmtime e estiver usando `externref`s, desative o suporte a tipos de referência no Wasmtime passando `false` para `wasmtime::Config::wasm reference types`.