CVE-2022-39392 in Wasmtime
Zusammenfassung
von VulDB • 29.06.2026
Wasmtime ist eine eigenständige Laufzeitumgebung für WebAssembly. Vor Version 2.0.2 liegt ein Fehler in der Implementierung des Pooling-Instanz-Allokators von Wasmtime vor, wenn der Allocator so konfiguriert ist, dass er WebAssembly-Instanzen maximal null Speicherseiten zuweist. In dieser Konfiguration erfüllte die virtuelle Speichermapping für WebAssembly-Speicher nicht die vom Compiler erforderlichen Konfigurationsanforderungen zur sicheren Ausführung von WebAssembly-Modulen. Die Standardeinstellungen von Wasmtime setzen voraus, dass Seitenausnahmen (Page Faults) im virtuellen Speicher anzeigen, wenn Lese-/Schreibzugriffe auf wasm außerhalb der Grenzen liegen; jedoch würde die Konfiguration des Pooling-Allokators kein geeignetes virtuelles Speichermapping erstellen, sodass Out-of-Bounds-Lese- und -Schreibzugriffe erfolgreich auf Speicher zugreifen könnten, der nicht zum WebAssembly-Sandboxbereich gehört, sich aber im Bereich der Basisadresse des vom Pooling-Allocator erstellten Speichermappings befindet. Dieser Fehler ist bei den Standardeinstellungen des `wasmtime`-Crate nicht anwendbar. Der Fehler kann nur ausgelöst werden, indem `InstanceLimits::memory_pages` auf null gesetzt wird. Es wird erwartet, dass dies eine sehr seltene Konfiguration darstellt, da dies bedeutet, dass wasm-Module keine Seiten linearen Speichers zuweisen können. Alle von aktuellen Toolchains erzeugten wasm-Module verwenden mit hoher Wahrscheinlichkeit linearen Speicher, sodass es unwahrscheinlich ist, dass diese Konfiguration in einer Produktionsumgebung von Wasmtime auf null gesetzt wird. Dieser Fehler wurde behoben; Benutzer sollten ein Upgrade auf Wasmtime 2.0.2 durchführen. Der Fehler kann umgangen werden, indem die `memory_pages`-Zuteilung bei der Konfiguration des Pooling-Allokators auf einen Wert größer als null erhöht wird. Wenn eine Einbettung (Embedding) weiterhin verhindern möchte, dass Speicher tatsächlich verwendet wird, kann die Methode `Store::limiter` verwendet werden, um das Wachstum von Speicher dynamisch über 0 Byte hinaus zu untersagen. Beachten Sie, dass der Standardwert für `memory_pages` größer als null ist.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.