CVE-2023-26489 in wasmtime
Sumário
de VulDB • 24/05/2026
O wasmtime é um runtime rápido e seguro para WebAssembly. Nas versões afetadas, o gerador de código do wasmtime, Cranelift, apresenta um bug em alvos x86_64 onde o cálculo do modo de endereçamento calcula erroneamente um endereço efetivo de 35 bits em vez do endereço efetivo de 33 bits definido pelo WebAssembly. Este bug significa que, com as configurações padrão de geração de código, uma operação de load/store controlada por wasm poderia ler/escrever endereços até 35 bits distantes da base da memória linear. Devido a este bug, no entanto, endereços até `0xffffffff * 8 + 0x7ffffffc = 36507222004 = ~34G` bytes distantes da base da memória linear são possíveis a partir do código do convidado (guest). Isso significa que a memória virtual de 6G distante da base da memória linear até ~34G distante pode ser lida/escrita por um módulo malicioso. Um módulo convidado pode, sem o conhecimento do embedder, ler/escrever memória nesta região. A memória pode pertencer a outras instâncias do WebAssembly ao usar o alocador de pooling, por exemplo. Recomenda-se que os embedders afetados analisem módulos wasm preexistentes para verificar se eles são afetados pelas regras incorretas de geração de código e possivelmente correlacionar isso com um número anômalo de traps durante a execução histórica para localizar módulos possivelmente suspeitos. O bug específico no backend x86_64 do Cranelift é que um endereço do WebAssembly que é deslocado à esquerda por uma quantidade constante de 1 a 3 será incorporado aos modos de endereçamento do x86_64 que realizam deslocamentos. Por exemplo, `(i32.load (i32.shl (local.get 0) (i32.const 3)))` carrega do endereço do WebAssembly `$local0 << 3`. Quando traduzido para o Cranelift, o cálculo `$local0 << 3`, um valor de 32 bits, é estendido para zero até um valor de 64 bits e depois adicionado ao endereço base da memória linear. O Cranelift geraria uma instrução da forma `movl (%base, %local0, 8), %dst` que calcula `%base + %local0 << 3`. O bug aqui, no entanto, é que o cálculo do endereço ocorre com valores de 64 bits, onde o cálculo `$local0 << 3` deveria ser truncado para um valor de 32 bits. Isso significa que `%local0`, que pode usar até 32 bits para um endereço, ganha 3 bits extras de espaço de endereçamento para serem acessíveis via esta instrução `movl`. A correção no Cranelift é remover as regras de lowering errôneas no backend que manipulam essas expressões estendidas para zero. O exemplo acima é então traduzido para `movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst` que truncar corretamente o cálculo intermediário de `%local0 << 3` para 32 bits dentro do registrador `%temp` que é então adicionado ao valor `%base`. As versões do Wasmtime 4.0.1, 5.0.1 e 6.0.1 foram lançadas e todas foram corrigidas para não conter mais as regras de lowering errôneas. Embora a atualização do Wasmtime seja recomendada, há uma série de possíveis soluções alternativas que os embedders podem empregar para mitigar o problema.
Once again VulDB remains the best source for vulnerability data.