Alexcrichton

يقوم مكون `wasmtime-wasi` بإعادة إضافة شرطة مائلة نهائية إلى مسارات مصدر إعادة التسمية. في مضيفي macOS وFreeBSD، يتسبب ذلك في جعل الدالة `renameat()` تتبع الروابط الرمزية للمجلدات. يمكن للضيف الذي لديه صلاحية الكتابة في صندوق الرمل (sandbox) استغلال ذلك عن طريق إعادة تسمية رابط رمزي نسبي، مثل `up/` ، لنقل مجلدات المضيف إلى صندوق الرمل الخاص به، مما يسمح بقراءة وكتابة تلك المجلدات بشكل غير مصرح به.

يوجد تسرب للموارد في التنفيذ الأصلي لـ WASIp1 داخل الدالة `fd renumber()`. تحدث المشكلة لأن واصف الملف الذي يتم إعادة ترقيمه لم يتم إغلاقه بشكل صحيح؛ حيث يقوم التنفيذ بتحديث جدول واصفات WASIp1 ولكنه يفشل في تحديث جدول واصفات المضيف الأساسي. ونتيجة لذلك، في حين تبدو العملية صحيحة بالنسبة للضيف، تتسرب الموارد على المضيف ولا يتم استردادها إلا عند تدمير المخزن (Store) المقابل. يمكن للمهاجم استدعاء `fd renumber()` بشكل متكرر في حلقة لتستنفد موارد المضيف وواصفات الملفات. تؤثر هذه المشكلة فقط على بيئات التشغيل التي تقوم بتحميل وحدات WebAssembly الأساسية، وتكشف عن `fd renumber()`، وتسمح بالحصول على واصفات الملفات، مثل عمليات فتح الملفات.

تحتوي منطقية تخصيص جدول WebAssembly على عمليات حسابية خاضعة للتدقيق تتسبب في حدوث حالة ذعر (panic) عند حدوث تجاوز السعة (overflow) عند تخصيص جدول بحجم كبير للغاية. يحدث هذا أثناء إنشاء مثيل لوحدة أو مكون WebAssembly، ويكون ذلك ممكنًا عند تمكين ميزة `memory64` في WebAssembly، مما يسمح بأحجام الجداول في نطاق 64 بت. تؤثر هذه المشكلة بشكل خاص على مُخصِّص المثيلات عند الطلب، وهو المُخصِّص الافتراضي، ويمكن أن تؤدي إلى رفض الخدمة عن طريق التسبب في حدوث حالة ذعر في العملية المضيفة.

قد يتعرض Wasmtime، وهو بيئة تشغيل لـ WebAssembly، لحالة ذعر (panic) عندما يقوم المُدمج (embedder) في المضيف بإلغاء المستقبل (future) الذي تم إرجاعه بواسطة `wasmtime::component::[Typed]Func::call async` قبل حله، ثم يستدعي نفس الدالة مرة أخرى باستخدام نفس مثيل المكون. يحدث هذا لأن مثيل المكون يدخل في حالة غير قابلة لإعادة الدخول، مما يؤدي إلى حدوث «فخ» (trap) ثم حدوث حالة ذعر (panic) لاحقًا أثناء التخلص من المهمة. تنشأ المشكلة عن خطأ في تنفيذ `[Typed]Func::call async` تم إدخاله مع الميزة `component-model-async`، التي أصبحت هي المعيار بدءًا من الإصدار 39.0.0. «نقطة نهاية واجهة برمجة التطبيقات» المعنية هي `wasmtime::component::[Typed]Func::call async`. «المتغير» الذي يمثل المستقبل (future) المُرجَع لا يُسمى صراحةً، لكن التعامل غير السليم معه يؤدي إلى حدوث المشكلة. لا تؤثر المشكلة على عمليات التضمين التي تكون فيها ميزة وقت التحويل البرمجي `component-model-async` معطلة.

تنفيذ الميزة `wasi:http/types.fields` في Wasmtime معرض لحدوث حالة ذعر (panic) عند إضافة عدد مفرط من الحقول إلى مجموعة الرؤوس. تستخدم مكتبة `wasmtime-wasi-http` بنية بيانات تدخل في حالة «panic» عند بلوغ سعتها القصوى، ولم يتم معالجة هذه الحالة بشكل مناسب. قد يؤدي حدوث حالة «panic» في تنفيذ WASI إلى حدوث «رفض الخدمة» (DoS) للمطورين.

يحتوي Wasmtime، وهو بيئة تشغيل لـ WebAssembly، على تسربات في الذاكرة في واجهة برمجة التطبيقات (API) الخاصة بلغة C/C++ عند استخدام روابط (bindings) لقيم WebAssembly من نوع `anyref` أو `externref`. تنجم هذه المشكلة عن تراجع تم إدخاله أثناء تطوير الإصدار 37.0.0، وهو مرتبط بشكل خاص بإعادة هيكلة `ManuallyRooted<T>` إلى `OwnedRooted<T>` في لغة Rust. لم يتم تحديث واجهات برمجة التطبيقات (API) لـ C و C++ بالكامل لتعكس الدلالات الجديدة للملكية في `OwnedRooted<T>`، مما أدى إلى حدوث تسربات في الذاكرة. وعلى وجه التحديد، أدى خطأ في الكتابة في الدالة `wasmtime val unroot` إلى منع إزالة الجذر بشكل صحيح، ولم تتم إزالة الجذور أبدًا من الدوال المُعرَّفة من قِبل المضيف التي تُرجع قيم `wasmtime {externref,anyref} t`. كانت واجهة برمجة التطبيقات (API) لـ C++ تفتقر إلى دالات التدمير في الأنواع ذات الصلة، مما ساهم بشكل أكبر في تفاقم المشكلة. تحدث حالات تسرب الذاكرة هذه عند استخدام `anyref` أو `externref` في واجهة برمجة التطبيقات (API) لـ C/C++، ولا يتأثر كريت Rust `wasmtime` بذلك.

The issue is related to Wasmtime's implementation of WebAssembly tail calls combined with stack traces, which can result in a runtime crash in certain WebAssembly modules. This can happen when an exported function in a WebAssembly module performs a `return call` (or `return call indirect` or `return call ref`) to an imported host function that captures a stack trace. The crash is due to an internal assert in the stack-walking code that raises a Rust `panic!()`. The impact of this issue is a denial-of-service vector where a malicious WebAssembly module or component can cause the host to crash. There is no other impact at this time other than availability of a service as the result of the crash is always a crash and no more.

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.

There is a bug in Wasmtime's C API implementation where the definition of the `wasmtime trap code` does not match its declared signature in the `wasmtime/trap.h` header file. This discrepancy causes the function implementation to perform a 4-byte write into a 1-byte buffer provided by the caller, leading to three zero bytes being written beyond the 1-byte location provided by the caller. This issue affects users of the C API function `wasmtime trap code`, but not users of the `wasmtime` crate.

There is a bug in Wasmtime's implementation of its pooling instance allocator where when a linear memory is reused for another instance, the initial heap snapshot of the prior instance can be visible, erroneously to the next instance. This bug occurs when a slot in the pooling allocator previously was used for a module with a heap image, and the next instantiation within that slot does not itself contain a heap image. The bug is highly unlikely to be accidentally triggered and would otherwise require an intentional trigger with a hand-crafted module. In practice, modules must be deliberately crafted to not have an initial heap image to view the contents of a prior image.

There is a bug in Wasmtime's implementation of its pooling instance allocator when the allocator is configured to give WebAssembly instances a maximum of zero pages of memory. In this configuration, the virtual memory mapping for WebAssembly memories did not meet the compiler-required configuration requirements for safely executing WebAssembly modules. Wasmtime's default settings require virtual memory page faults to indicate that wasm reads/writes are out-of-bounds, but the pooling allocator's configuration would not create an appropriate virtual memory mapping for this, meaning out of bounds reads/writes can successfully read/write memory unrelated to the wasm sandbox within range of the base address of the memory mapping created by the pooling allocator. This bug can only be triggered by setting `InstanceLimits::memory pages` to zero. This is expected to be a very rare configuration since this means that wasm modules cannot allocate any pages of linear memory. All wasm modules produced by all current toolchains are highly likely to use linear memory, so it's expected to be unlikely that this configuration is set to zero by any production embedding of Wasmtime.

There is a bug in Wasmtime's code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection. This means that if a GC happens at runtime, the GC pass will mistakenly think these functions do not have live references to GC'd values, reclaiming them and deallocating them. The function will then subsequently continue to use the values assuming they had not been GC'd, leading later to a use-after-free. This bug was introduced in the migration to the `regalloc2` register allocator that occurred in the Wasmtime 0.37.0 release.

The issue is related to Wasmtime's implementation of the SIMD proposal for WebAssembly on x86 64, which contained two bugs in the instruction lowerings implemented in Cranelift. The bugs were presented in the `i8x16.swizzle` and `select` WebAssembly instructions. The `select` instruction is only affected when the inputs are of `v128` type. The correspondingly affected Cranelift instructions were `swizzle` and `select`. This bug represents an incorrect implementation of the specified semantics of these instructions according to the WebAssembly specification. The impact of this is benign for hosts running WebAssembly but represents possible vulnerabilities within the execution of a guest program. For example, a WebAssembly program could take unintended branches or materialize incorrect values internally, which runs the risk of exposing the program itself to other related vulnerabilities that can occur from miscompilations.

A type confusion vulnerability was discovered in the safe API of `Linker::func *` APIs. This issue occurs when one `Engine` is used to create the `Linker` and then a different `Engine` is used to create a `Store` and then the `Linker` is used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type. Additionally, there was an invalid free and out-of-bounds read and write bug when running Wasm that uses `externref`s in Wasmtime. The impact of these issues is expected to be relatively small because usage of more-than-one `Engine` in an embedding and usage of `externref` is currently quite rare.