Сканер-ВСкаталог уязвимостей · v4.2

Главная Каталог Источники CWE CAPEC ATT&CK Меры защиты Продукты Вендоры Документация

← Вернуться к списку

Bytecodealliance›Приложениеnvd,anchore_overrides

Wasmtime

Уязвимости

40

Эксплуатируемые

0

Макс. CVSS

9.9

Макс. EPSS

0.01283

Распределение по критичности

Критический

5

Высокий

6

Средний

20

Низкий

9

Затронутые диапазоны версий

0.19.0–0.30.00.26.0–0.30.00.34.0–0.34.20.37.0–0.38.20.37.0–4.0.110.0.0–10.0.219.0.0–19.0.119.0.0–21.0.221.0.0–21.0.225.0.0–36.0.728.0.0–36.0.729.0.0–36.0.530.0.0–36.0.832.0.0–36.0.738.0.0–38.0.338.0.1–38.0.439.0.0–40.0.443.0.0–43.0.1< 0.30.0< 0.33.1< 0.38.1< 1.0.2< 24.0.2< 24.0.4

Также сопоставлено как (исходные строки): wasmtime,cranelift-codegen

Топ уязвимостей

CVE-2023-26489wasmtime - это быстрая и безопасная среда выполнения для WebAssembly. В затронутых версиях генератор кода wasmtime, Cranelift, имеет ошибку на целях x86_64, где вычисление режима адреса ошибочно вычисляет 35-битный эффективный адрес вместо определенного WebAssembly 33-битного эффективного адреса. Эта ошибка означает, что при настройках кодогенерации по умолчанию операция загрузки/сохранения, контролируемая wasm, может читать/записывать адреса на расстоянии до 35 бит от базы линейной памяти. Из-за этой ошибки, однако, адреса на расстоянии до `0xffffffff * 8 + 0x7ffffffc = 36507222004 = ~34G` байт от базы линейной памяти возможны из гостевого кода. Это означает, что виртуальную память на расстоянии 6G от базы линейной памяти до ~34G можно читать/записывать вредоносным модулем. Гостевой модуль может без ведома встраивателя читать/записывать память в этом регионе. Память может принадлежать другим экземплярам WebAssembly при использовании пулингового аллокатора, например. Рекомендуется, чтобы затронутые встраиватели проанализировали существующие модули wasm, чтобы увидеть, затронуты ли они неправильными правилами кодогенерации, и, возможно, сопоставили это с аномальным количеством ловушек во время исторического выполнения, чтобы найти, возможно, подозрительные модули. Конкретная ошибка в бэкэнде Cranelift x86_64 заключается в том, что адрес WebAssembly, который сдвигается влево на постоянную величину от 1 до 3, будет свернут в режимы адресации x86_64, которые выполняют сдвиги. Например, `(i32.load (i32.shl (local.get 0) (i32.const 3)))` загружается из адреса WebAssembly `$local0 << 3`. При преобразовании в Cranelift вычисление `$local0 << 3`, 32-битное значение, расширяется нулем до 64-битного значения, а затем добавляется к базовому адресу линейной памяти. Cranelift сгенерирует инструкцию вида `movl (%base, %local0, 8), %dst`, которая вычисляет `%base + %local0 << 3`. Ошибка здесь, однако, заключается в том, что вычисление адреса происходит с 64-битными значениями, где вычисление `$local0 << 3` должно было быть усечено до 32-битного значения. Это означает, что `%local0`, который может использовать до 32 бит для адреса, получает 3 дополнительных бита адресного пространства, доступных через эту инструкцию `movl`. Исправление в Cranelift заключается в удалении ошибочных правил понижения в бэкэнде, которые обрабатывают эти выражения, расширенные нулем. Приведенный выше пример затем преобразуется в `movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst`, который правильно усекает промежуточное вычисление `%local0 << 3` до 32 бит внутри регистра `%temp`, который затем добавляется к значению `%base`. Wasmtime версии 4.0.1, 5.0.1 и 6.0.1 были выпущены и исправлены, чтобы больше не содержать ошибочные правила понижения. Хотя рекомендуется обновить Wasmtime, существует ряд возможных обходных путей, которые встраиватели могут использовать для смягчения этой проблемы, если обновление невозможно. Обратите внимание, что ни один из этих обходных путей не включен по умолчанию и требует явной настройки: 1. Опция `Config::static_memory_maximum_size(0)` может быть использована для принудительного выполнения явной проверки границ для всех обращений к линейной памяти. Это выполнит проверку границ отдельно от вычисления режима адреса, которое правильно вычисляет эффективный адрес загрузки/сохранения. Обратите внимание, что это может оказать большое влияние на производительность выполнения модулей WebAssembly. 2. Опция `Config::static_memory_guard_size(1 << 36)` может быть использована для значительного увеличения количества страниц защиты, размещенных после линейной памяти. Это гарантирует, что обращения к памяти на расстоянии до 34G будут семантически правильными, зарезервировав не отображенную память для экземпляра. Обратите внимание, что это резервирует очень большой объем виртуальной памяти на экземпляр и может значительно уменьшить максимальное количество одновременно выполняемых экземпляров. 3. Если возможно использование хоста, отличного от x86_64, то это также позволит обойти эту ошибку. Эта ошибка не затрагивает бэкэнд Wasmtime или Cranelift AArch64, например.

CVE-2022-39394Wasmtime — это автономная среда выполнения для WebAssembly. До версии 2.0.2 существует ошибка в реализации C API Wasmtime, когда определение `wasmtime_trap_code` не соответствует объявленной сигнатуре в файле заголовка `wasmtime/trap.h`. Это несоответствие приводит к тому, что реализация функции выполняет 4-байтовую запись в 1-байтовый буфер, предоставленный вызывающим. Это может привести к записи трех нулевых байтов за пределами 1-байтового местоположения, предоставленного вызывающим. Эта ошибка была исправлена, и пользователям следует обновиться до Wasmtime 2.0.2. Эту ошибку можно обойти, предоставив 4-байтовый буфер, приведенный к 1-байтовому буферу, при вызове `wasmtime_trap_code`. Пользователи крейта `wasmtime` не подвержены этой проблеме, только пользователи функции C API `wasmtime_trap_code` подвержены этой проблеме.

CVE-2022-24791Wasmtime — это автономная JIT-среда выполнения для WebAssembly, использующая Cranelift. Существует уязвимость использования после освобождения в Wasmtime при одновременном запуске Wasm, использующего externrefs, и включении прерывания эпохи в Wasmtime. Если вы явно не включаете прерывание эпохи (оно отключено по умолчанию), то вы не подвержены уязвимости. Если вы явно отключаете предложение типов ссылок Wasm (оно включено по умолчанию), то вы также не подвержены уязвимости. Использование после освобождения вызвано тем, что Cranelift не может генерировать карты стека, когда внутри холодных блоков есть точки безопасности. Холодные блоки возникают при включенном прерывании эпохи. Холодные блоки излучаются в конце скомпилированных функций и изменяют порядок излучения блоков по сравнению с определенным. Эта переупорядочение случайно заставило Cranelift пропустить излучение некоторых карт стека, потому что он ожидал излучать карты стека в порядке определения блоков, а не в порядке излучения блоков. Когда Wasmtime в конечном итоге собирал мусор, он не мог найти живые ссылки в стеке из-за отсутствующих карт стека, думал, что это неиспользуемый мусор, и поэтому возвращал их. Затем после окончания сбора код Wasm мог использовать возвращенные слишком рано ссылки, что является использованием после освобождения. Исправления были выпущены в версиях 0.34.2 и 0.35.2, которые устраняют уязвимость. Всем пользователям Wasmtime рекомендуется обновиться до этих исправленных версий. Если обновление в данный момент невозможно, вы можете избежать уязвимости, либо: отключив предложение типов ссылок Wasm, config.wasm_reference_types(false); либо отключив прерывание эпохи, если вы ранее его включали. config.epoch_interruption(false).

CVE-2026-34987Wasmtime - это время работы для WebAssmbly. С 25.0.0 до 36.0.7, 42.0.2 и 43.0.1, Wasmtime с его Winch (базовый) компилятором без по умолчанию бэкэнд может позволить правильно построенному гостю Wasm получить доступ к памяти хостов за пределами своей линейной песочницы памяти. Эта уязвимость требует использования компилера Winch (-Ccompiler=winch). По умолчанию Wasmtime использует свой бэкэнд Cranelift, а не Winch. С Winch в теории присутствует одно и то же неверное предположение как на aarch64, так и на x86-64. Дело aarch64 имеет наблюдаемое доказательство концепции, в то время как случай x86-64 является теоретическим и может быть недоступен на практике. Эта ошибка компиляции Winch может позволить гостю Wasm получить доступ к памяти до или после области линейной памяти, независимо от того, настроены ли области до или после защиты. Доступный диапазон в первоначальном доказательстве концепции ошибки составляет до 32KiB до начала памяти или ~4GiB после начала памяти, независимо от размера областей до или после защиты или использования явной проверки границ на основе охранного региона. Тем не менее, основная ошибка предполагает, что 32-битная компенсация памяти, хранящаяся в 64-битном регистре, имеет свои верхние биты, когда она не может, и поэтому тесно связанные варианты первоначального доказательства концепции могут иметь доступ к действительно произвольной памяти в процессе. Это может привести к ошибке сегментации процесса (DoS) хост-процесса, произвольной утечке данных из процесса хоста или с записью, потенциально произвольной RCE. Эта уязвимость зафиксирована в 36.0.7, 42.0.2 и 43.0.1.

CVE-2026-34971Wasmtime - это время работы для WebAssembly. С 32.0.0 до 36.0.7, 42.0.2 и 43.0.1, бэкэнд компиляции Cranelift Wasmtime содержит ошибку на aarch64 при выполнении определенной формы кучи доступа, что означает, что неправильный адрес доступен. В сочетании с явными границами проверяет гостевой модуль WebAssembly это может создать ситуацию, когда есть два расходных вычисления для одного и того же адреса: один для адреса в границах и один для загрузки адреса. Эта разница в работе по адресу означает, что гостевой модуль может пройти проверку границ, но затем загрузить другой адрес. В сочетании это обеспечивает произвольное чтение/письменное примитивное для гостевой WebAssembly при доступе к памяти хоста. Это выход из песочницы, поскольку гости могут читать / писать произвольную память хозяина. Эта уязвимость имеет несколько ингредиентов, все из которых должны быть выполнены, чтобы эта ситуация произошла и обойти ограничения песочницы. Эта неправильно компилируемая форма нагрузки возникает только на 64-битных линейных воспоминаниях WebAssembly, или когда включена Config::wasm_memory64. 32-разрядная веб-сборка не затрагивается. Смягчение спектра или ловушек на основе сигналов должны быть отключены. Когда позволяют смягчение спектра, то не создается оскорбительная форма нагрузки. Когда ловушка на основе сигналов отключена, смягчение спектра также автоматически отключается. Специфическая ошибка в Cranelift представляет собой ошибку в нагрузке формы (iadd(base, ihl(index, амт))), где он является постоянным. Значение Mt неправильно маскируется, чтобы проверить, является ли оно определенным значением, и эта неправильный маска означает, что Cranelift может ошибочно сопоставить это правило понижения во время выбора инструкций, отклоняясь от семантики WebAssembly и Cranelift. Это неправильное снижение, например, загрузило бы адрес гораздо дальше, чем предполагало, поскольку правильное вычисление адреса обернулись бы до меньшего значения в установленном. Эта уязвимость зафиксирована в пунктах 36.0.7, 42.0.2 и 43.0.1.

CVE-2023-30624Wasmtime — это автономная среда выполнения для WebAssembly. До версий 6.0.2, 7.0.1 и 8.0.1 реализация Wasmtime управления состоянием для каждого экземпляра, таким как таблицы и память, содержит неопределенное поведение на уровне LLVM. Было обнаружено, что это неопределенное поведение вызывает проблемы на уровне среды выполнения при компиляции с LLVM 16, что приводит к оптимизации некоторых записей, которые имеют решающее значение для правильности. Известно, что уязвимые версии Wasmtime, скомпилированные с Rust 1.70, который в настоящее время находится в бета-версии, или более поздней версии, имеют неправильно скомпилированные функции. В настоящее время неизвестно, что версии Wasmtime, скомпилированные с текущим стабильным выпуском Rust, 1.69, и более ранними версиями, имеют какие-либо проблемы, но теоретически могут проявлять потенциальные проблемы. Основная проблема заключается в том, что состояние среды выполнения Wasmtime для экземпляра включает структуру, определенную Rust, под названием `Instance`, которая имеет замыкающую структуру `VMContext` после нее. Эта структура `VMContext` имеет определенную во время выполнения компоновку, которая является уникальной для каждого модуля. Это представление не может быть выражено безопасным кодом в Rust, поэтому для поддержания этого состояния требуется `unsafe` код. Однако код, выполняющий это, имеет методы, которые принимают `&self` в качестве аргумента, но изменяют данные в части `VMContext` выделения. Это означает, что указатели, полученные из `&self`, изменяются. Обычно это не разрешено, за исключением наличия `UnsafeCell`, в Rust. При компиляции в LLVM эти функции имеют параметры `noalias readonly`, что означает, что запись через указатели является UB. Внутреннее представление и управление `VMContext` Wasmtime было обновлено для использования методов `&mut self`, где это уместно. Кроме того, планируется, что вскоре на ветке `main` будут выполняться инструменты проверки `unsafe` кода в Rust, такие как `cargo miri`, для исправления любых проблем на уровне Rust, которые могут быть использованы в будущих версиях компилятора. Предварительно скомпилированные двоичные файлы, доступные для Wasmtime из выпусков GitHub, были скомпилированы максимум с LLVM 15, поэтому, как известно, не являются уязвимыми. Однако, как упоминалось выше, по-прежнему рекомендуется обновиться. Были выпущены версии Wasmtime 6.0.2, 7.0.1 и 8.0.1, которые содержат исправление, необходимое для правильной работы на LLVM 16, и не имеют известного UB на LLVM 15 и более ранних версиях. Если Wasmtime скомпилирован с Rust 1.69 и более ранними версиями, в которых используется LLVM 15, то, как известно, нет никаких проблем. Однако существует теоретическая возможность использования неопределенного поведения, поэтому пользователям рекомендуется обновиться до исправленной версии Wasmtime. Пользователи, использующие бета-версию Rust (1.70 на данный момент) или ночную версию Rust (1.71 на данный момент), должны обновиться до исправленной версии, чтобы работать правильно.

CVE-2022-31146Wasmtime — это автономная среда выполнения для WebAssembly. В генераторе кода Wasmtime, Cranelift, есть ошибка, из-за которой в функциях, использующих типы ссылок, может отсутствовать метаинформация, необходимая для сборки мусора во время выполнения. Это означает, что если сборка мусора происходит во время выполнения, то проход сборки мусора ошибочно сочтет, что эти функции не имеют активных ссылок на значения, собранные сборщиком мусора, возвращая их и освобождая. Затем функция продолжит использовать значения, предполагая, что они не были собраны сборщиком мусора, что впоследствии приведет к использованию после освобождения. Эта ошибка была внесена при переходе на распределитель регистров `regalloc2`, который произошел в выпуске Wasmtime 0.37.0 2022-05-20. Эта ошибка была исправлена, и пользователям следует обновиться до Wasmtime версии 0.38.2. Смягчить последствия этой проблемы можно, отключив предложение типов ссылок, передав `false` в `wasmtime::Config::wasm_reference_types` или понизив версию до Wasmtime 0.36.0 или более ранней.

CVE-2022-39393В Wasmtime, независимой среде выполнения для WebAssembly, обнаружена ошибка в реализации алгоритма распределения экземпляров пула. В версиях до 2.0.2 и 1.0.2 существует ошибка, при которой начальный снимок кучи предыдущего экземпляра может быть ошибочно видим для следующего экземпляра. Эта ошибка была исправлена в Wasmtime 2.0.2 и 1.0.2 [1]. Среди рекомендуемых способов устранения этой уязвимости - отключение пула распределителя и отключение функции `memory-init-cow` [2]. Источники: - [1] https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-wh6w-3828-g9qf - [2] https://github.com/bytecodealliance/wasmtime/commit/2614f2e9d2d36805ead8a8da0fa0c6e0d9e428a0

CVE-2022-23636Wasmtime — это среда выполнения с открытым исходным кодом для WebAssembly и WASI. До версий 0.34.1 и 0.33.1 существует ошибка в аллокаторе пула экземпляров в среде выполнения Wasmtime, когда сбой при создании экземпляра для модуля, который определяет глобальную `externref`, приведет к недопустимому удалению `VMExternRef` через неинициализированный указатель. Чтобы экземпляр был уязвим для этой проблемы, должно выполняться несколько условий, перечисленных в рекомендациях по безопасности GitHub. Разработчики считают, что фактическое влияние этой ошибки относительно невелико, поскольку использование `externref` все еще является необычным, и без ограничителя ресурсов, настроенного в `Store`, что не является конфигурацией по умолчанию, можно вызвать ошибку только из ошибки, возвращенной `mprotect` или `VirtualAlloc`. Обратите внимание, что в Linux с включенной функцией `uffd` можно вызвать ошибку только из ограничителя ресурсов, поскольку вызов `mprotect` пропускается. Ошибка исправлена в версиях 0.34.1 и 0.33.1, и пользователям рекомендуется обновиться как можно скорее. Если невозможно обновиться до версии 0.34.1 или 0.33.1 крейта `wasmtime`, рекомендуется отключить поддержку предложения типов ссылок, передав `false` в `Config::wasm_reference_types`. Это предотвратит полную загрузку модулей, использующих `externref`.

CVE-2022-31169Wasmtime — это автономная среда выполнения для WebAssembly. Существует ошибка в генераторе кода Wasmtime, Cranelift, для целей AArch64, где постоянные делители могут привести к неправильным результатам деления во время выполнения. Это затрагивает Wasmtime до версии 0.38.2 и Cranelift до 0.85.2. Эта проблема затрагивает только платформу AArch64. Другие платформы не затронуты. Правила перевода для констант не учитывали, следует ли выполнять расширение знака или нуля, что приводило к помещению неправильного значения в регистр при обнаружении деления. Влияние этой ошибки заключается в том, что программы, выполняющиеся в песочнице WebAssembly, будут вести себя не в соответствии со спецификацией WebAssembly. Это означает, что гипотетически возможно, что выполнение в песочнице пойдет наперекосяк, и программы WebAssembly могут давать неожиданные результаты. Это не должно влиять на хосты, выполняющие WebAssembly, но влияет на правильность гостевых программ. Эта ошибка была исправлена в Wasmtime версии 0.38.2 и cranelift-codegen 0.85.2. Нет известных обходных путей.

CVE-2022-39392Wasmtime — это автономная среда выполнения для WebAssembly. До версии 2.0.2 существует ошибка в реализации Wasmtime своего пула аллокатора экземпляров, когда аллокатор настроен так, чтобы предоставить экземплярам WebAssembly максимум ноль страниц памяти. В этой конфигурации отображение виртуальной памяти для памяти WebAssembly не соответствовало требованиям конфигурации, необходимым компилятору для безопасного выполнения модулей WebAssembly. Параметры Wasmtime по умолчанию требуют сбоев страниц виртуальной памяти, чтобы указать, что операции чтения/записи wasm находятся вне границ, но конфигурация пула аллокатора не создаст соответствующее отображение виртуальной памяти для этого, что означает, что операции чтения/записи вне границ могут успешно читать/записывать память, не связанную с песочницей wasm, в пределах диапазона базового адреса отображения памяти, созданного пулом аллокатора. Эта ошибка не применима при настройках по умолчанию крейта `wasmtime`. Эта ошибка может быть вызвана только установкой `InstanceLimits::memory_pages` в ноль. Ожидается, что это будет очень редкая конфигурация, поскольку это означает, что модули wasm не могут выделять страницы линейной памяти. Все модули wasm, созданные всеми текущими цепочками инструментов, с большой вероятностью будут использовать линейную память, поэтому маловероятно, что эта конфигурация будет установлена в ноль каким-либо производственным внедрением Wasmtime. Эта ошибка была исправлена, и пользователям следует обновиться до Wasmtime 2.0.2. Эту ошибку можно обойти, увеличив объем `memory_pages` при настройке пула аллокатора до значения больше нуля. Если встраивание по-прежнему хочет предотвратить фактическое использование памяти, метод `Store::limiter` можно использовать для динамического запрета увеличения памяти за пределы 0 байт. Обратите внимание, что значение `memory_pages` по умолчанию больше нуля.

CVE-2026-34941Wasmtime - это время работы для WebAssembly. До 24.0.7, 36.0.7, 42.0.2 и 43.0.1, Wasmtime содержит уязвимость, при которой при перекодировании строки UTF-16 в компонентной модели latin1+utf16, кодируя ее, неправильно проверяла бы длину байта входной строки при выполнении проверки границ. В частности, было проверено количество кодовых блоков вместо длины байт, что в два раза больше кодовых единиц. Эта уязвимость может заставить хоста читать за пределами линейной памяти WebAssembly в попытке перекодировать несуществующие байты. В конфигурации Wasmtime по умолчанию это будет читать ненанесенную напоказ память на странице охраны, прерывая процесс сегфолтом. Однако Wasmtime может быть настроен без страниц охраны, что означало бы, что память хоста за пределами линейной памяти может быть прочитан и интерпретирована как UTF-16. Устройство segfault - это уязвимость отказа в обслуживании в Wasmtime, и, возможно, возможность читать за пределами линейной памяти также является уязвимостью. Обратите внимание, что чтение за пределами линейной памяти требует нестандартной настройки Wasmtime, в частности, с отключенными защитными страницами. Эта уязвимость зафиксирована в пункте 24.0.7, 36.0.7, 42.0.2 и 43.0.1.

CVE-2026-27572Wasmtime - это время работы для WebAssembly. До версий 24.0.6, 36.0.6, 4.0.04, 41.0.4 и 42.0.0, реализация Wasi: http/types.fields` ресурса `wasi: http/types.fields` подвержена панике, когда слишком много полей добавляется к набору заголовков. Внедрение Wasmtime в ящике Wasmtime-wasi-http' подкрепляется структурой данных, которая паникует, когда она достигает чрезмерной емкости, и это условие не было изящно обработано в Wasmtime. Паника в реализации WASI является вектором отказа в обслуживании для встраиваемых систем и рассматривается как уязвимость безопасности в Wasmtime. Время работы 24.0.6, 36.0.6, 40.0.4, 41.0.4 и 42.0.0 латайте эту уязвимость и возвращайте ловушку гостю вместо паники. В настоящее время нет никаких известных обходных пути. Embedders рекомендуется обновить до исправленной версии Wasmtime.

CVE-2026-27204Wasmtime - это время работы для WebAssembly. До версий 24.0.6, 36.0.6, 4.0.04, 41.0.4 и 42.0.0, реализация Wasmtime хост-интерфейсах WASI подвержена исчерпанию ресурсов, контролируемых гостями, на хосте. Wasmtime не установила надлежащим образом ограничения на распределение ресурсов, запрошенное гостями. Это служит вектором отказа в обслуживании. Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4 и 42.0.0 были выпущены с исправлением для этого выпуска. Эти версии не предотвращают эту проблему в их конфигурации по умолчанию, чтобы избежать нарушения ранее существовавшего поведения. Все версии Wasmtime имеют соответствующие ручки для предотвращения такого поведения, и Wasmtime 42.0.0-и-позже будут иметь эти ручки, настроенные по умолчанию, чтобы предотвратить эту проблему. Нет никаких известных обходных путей для этого вопроса без модернизации. Встраумам рекомендуется обновить и настроить свои вложения по мере необходимости, чтобы предотвратить, возможно, злонамеренных гостей от возникновения этой проблемы.

CVE-2026-27195Wasmtime - это время работы для WebAssembly. Начиная с Wasmtime 39.0.0, функция «компонент-модель-ассинк» стала функцией по умолчанию, что принесло с собой новую реализацию `[Typed]Func::call_async`, которая сделала ее способной вызывать асинтезируемые гостевые экспортные функции. Однако эта реализация имела ошибку, приводящую к панике при определенных обстоятельствах: во-первых, встраивание хоста вызывает `[Typed]Func::call_async` на функцию, экспортируемую компонентом, опрашивая возвращающийся `Future` один раз. Во-вторых, функция компонента дает контроль к времени выполнения асинхронного (например, Tokio), например, из-за вызова в функцию хоста, зарегистрированного с использованием `LinkerInstance::func_wrap_async` которая дает, или из-за прерывания эпохи. В-третьих, встраивание хозяина бросает «Будущее» после опроса один раз. Это оставляет компонентный экземпляр в невозвратном состоянии, поскольку у вызова никогда не было возможности завершить. В-четвертых, ведущая встраивает звонки `[Typed]Func::call_async` снова, опрашивая возвращающегося `Future`. Поскольку экземпляр компонента не может быть введен в этот момент, вызов ловучит, но не перед выделением задачи и нити для вызова. В-пятых, встраивание хозяина игнорирует ловушку и бросает «Будущее». Это вызывает панику из-за попытки выполнить поставленную выше задачу, которая паникует, поскольку нить еще не вышла. Когда ведущая, использующая затронутые версии Wasmtime, звонит `wasmtime:::component::[Typed]Func::call_async` на гостевом экспорте, а затем роняет возвращенное будущее, не дожидаясь его разрешения, а затем делает это снова с тем же экземпляром компонента, Wasmtime будет паниковать. Встраивания, которые имеют отключенную функцию компиляции «компонент-модель-ассинк» не имеют последствий. Для решения этой проблемы были исправлены время 40.0.4 и 41.0.4. Версий 42.0.0 и более поздних версий не затрагиваются. Если встраивание на самом деле не использует какие-либо функции компонент-модель-ассинкс, то отключение функции «компонент-модель-асинхронизация» может обойти эту проблему. Этот вопрос также может быть решен, гарантируя, что каждое `call_async` будущее ожидается до тех пор, пока оно не завершится, либо воздержаться от использования `Store` снова после того, как он не решен «голосование» в будущем.

CVE-2021-39219Wasmtime - это среда выполнения с открытым исходным кодом для WebAssembly и WASI. Wasmtime до версии 0.30.0 подвержен уязвимости, связанной с путаницей типов. Как библиотека Rust, крейт `wasmtime` четко помечает, какие функции являются безопасными, а какие - `unsafe`, гарантируя, что если потребители никогда не используют `unsafe`, то не должно быть возможно проблем с небезопасностью памяти в их внедрениях Wasmtime. Проблема была обнаружена в безопасном API API `Linker::func_*`. Ранее эти API были небезопасными, когда один `Engine` использовался для создания `Linker`, а затем другой `Engine` использовался для создания `Store`, а затем `Linker` использовался для создания экземпляра модуля в этом `Store`. Использование функций между `Engine` не поддерживается в Wasmtime, и это может привести к путанице типов указателей функций, что приведет к возможности безопасного вызова функции с неправильным типом. Для вызова этой ошибки требуется использование как минимум двух значений `Engine` во внедрении, а затем дополнительно использование двух разных значений с `Linker` (один во время создания `Linker`, а другой при создании экземпляра модуля с помощью `Linker`). Ожидается, что использование более одного `Engine` во внедрении относительно редко, поскольку `Engine` предназначен для использования в качестве глобально совместно используемого ресурса, поэтому ожидается, что влияние этой проблемы будет относительно небольшим. Реализованное исправление состоит в том, чтобы изменить это поведение на `panic!()` в Rust вместо того, чтобы молча разрешить это. Использование разных экземпляров `Engine` с `Linker` - это ошибка программиста, которую `wasmtime` перехватывает во время выполнения. Эта ошибка была исправлена, и пользователям следует обновиться до Wasmtime версии 0.30.0. Если вы не можете обновить Wasmtime и используете более одного `Engine` во внедрении, рекомендуется вместо этого использовать только один `Engine` для всей программы, если это возможно. `Engine` предназначен для использования в качестве глобально совместно используемого ресурса, подходящего для использования только одного для всего времени существования процесса. Если требуется использование нескольких `Engine`, следует проверить код, чтобы убедиться, что `Linker` используется только с одним `Engine`.

CVE-2021-39218Wasmtime - это среда выполнения с открытым исходным кодом для WebAssembly и WASI. В Wasmtime от версии 0.26.0 и до версии 0.30.0 присутствует уязвимость, связанная с нарушением безопасности памяти. Обнаружена недопустимая ошибка освобождения и чтения и записи за пределами границ при запуске Wasm, использующего `externref` в Wasmtime. Чтобы вызвать эту ошибку, Wasmtime должен запускать Wasm, использующий `externref`, хост создает ненулевые `externref`, Wasmtime выполняет сборку мусора (GC), и в стеке должен быть кадр Wasm, который находится в безопасной точке GC, где нет активных ссылок в этой безопасной точке, и есть безопасная точка с активными ссылками ранее в функции этого кадра. В этом сценарии Wasmtime будет неправильно использовать карту стека GC для безопасной точки из более ранней части функции вместо пустой безопасной точки. Это приведет к тому, что Wasmtime будет рассматривать произвольные слоты стека как `externref`, которые необходимо укоренить для GC. При *следующей* GC будет определено, что ничто не ссылается на эти поддельные `externref` (потому что ничто никогда не сможет ссылаться на них, потому что они на самом деле не `externref`), и тогда Wasmtime освободит их и запустит `<ExternRef as Drop>::drop` на них. Это приводит к освобождению памяти, которая не обязательно находится в куче (и не должна быть освобождена в данный момент, даже если бы она была), а также к потенциальным операциям чтения и записи за пределами границ. Даже если поддержка `externref` (через предложение типов ссылок) включена по умолчанию, если вы не создаете ненулевые `externref` в своем хост-коде или явно не запускаете GC, вы не можете быть затронуты этой ошибкой. У нас есть основания полагать, что фактическое влияние этой ошибки относительно невелико, поскольку использование `externref` в настоящее время довольно редко. Эта ошибка была исправлена, и пользователям следует обновиться до Wasmtime версии 0.30.0. Если вы не можете обновить Wasmtime в данный момент, вы можете избежать этой ошибки, отключив предложение типов ссылок, передав `false` в `wasmtime::Config::wasm_reference_types`.

CVE-2021-39216Wasmtime - это среда выполнения с открытым исходным кодом для WebAssembly и WASI. В Wasmtime от версии 0.19.0 и до версии 0.30.0 была ошибка использования после освобождения при передаче `externref` от хоста к гостевому контенту Wasm. Чтобы вызвать ошибку, необходимо явно передать несколько `externref` от хоста в экземпляр Wasm одновременно, либо передав несколько `externref` в качестве аргументов из хост-кода в функцию Wasm, либо вернув несколько `externref` в Wasm из функции возврата нескольких значений, определенной на хосте. Если у вас нет хост-кода, который соответствует одной из этих форм, то вы не подвержены влиянию. Если `VMExternRefActivationsTable` Wasmtime заполнилась до предела после передачи первого `externref`, то передача второго `externref` может вызвать сборку мусора. Однако первый `externref` не укореняется до тех пор, пока мы не передадим управление Wasm, и поэтому может быть возвращен сборщиком, если ничто другое не удерживает ссылку на него или иным образом не поддерживает его в живых. Затем, когда управление было передано Wasm после сборки мусора, Wasm мог использовать первый `externref`, который на данный момент уже был освобожден. У нас есть основания полагать, что фактическое влияние этой ошибки относительно невелико, поскольку использование `externref` в настоящее время довольно редко. Ошибка была исправлена, и пользователям следует обновиться до Wasmtime 0.30.0. Если вы пока не можете обновить Wasmtime, вы можете избежать ошибки, отключив поддержку типов ссылок в Wasmtime, передав `false` в `wasmtime::Config::wasm_reference_types`.

CVE-2026-35195Wasmtime - это время выполнения для WebAssembly. До 24.0.7, 36.0.7, 42.0.2 и 43.0.1 реализация Wasmtime транскодирования строк между компонентами содержит ошибку, при которой обратное значение релока гостевого компонента не проверяется до того, как хозяин попытается записать через указатель. Это позволяет гостю заставить хоста писать произвольные транскодированные строочные байты в произвольное местоположение до 4GiB от основания линейной памяти. Эти записи на хосте могут поразить незапланированную память или могут повредить структуры данных хостов в зависимости от конфигурации Wasmtime. Wasmtime по умолчанию резервы 4GiB виртуальной памяти для линейной памяти гостя означают, что эта ошибка по умолчанию на хостах заставит хостов поразить ненанесенную карту памяти и прервать процесс из-за неисправности. Однако Wasmtime может быть настроен на то, чтобы зарезервировать меньше памяти для гостя и удалить все страницы охраны, поэтому некоторые конфигурации Wasmtime могут привести к повреждению данных за пределами линейной памяти гостя, таких как структуры данных хоста или линейные воспоминания других гостей. Эта уязвимость зафиксирована в пунктах 24.0.7, 36.0.7, 42.0.2 и 43.0.1.

CVE-2026-35186Wasmtime - это время работы для WebAssembly. С 25.0.0 до 36.0.7, 42.0.2 и 43.0.1, бэкэнд компиляции Winch от Wasmtime содержит ошибку, в которой перевод оператора table.grow приводит к неправильной напечативанию результата. Для 32-битных таблиц это означает, что результат оператора, внутренне в Winch, помечается как 64-битное значение вместо 32-разрядного значения. Это недействительное внутреннее представление состояния компиляционера Winch усложняет дополнительные проблемы в зависимости от того, как потребляется значение. Основным последствием этой ошибки является то, что байты в адресном пространстве хоста могут храниться/читаться. Однако это применимо только к 16 байтам перед линейной памятью, поскольку единственное значительное значение возврата table.grow, которое может быть неправильно истолковано, составляет -1. Байты перед линейной памятью по умолчанию являются ненанозначной памятью. Однако Wasmtime обнаружит эту ошибку и прервет процесс, потому что Wasm не должен иметь доступа к этим байтам. В целом, этот баг в Winch представляет собой вектор DoS, сбивая процесс хоста, проблему правильности в Winch и возможную утечку до 16 байтов перед линейной памятью. Компиллер Wasmtime по умолчанию - Cranelift, а не Winch, а настройки Wasmtime по умолчанию должны размещать защитные страницы перед линейной памятью. Это означает, что конфигурация по умолчанию Wasmtime не затрагивается этой проблемой, и при явном выборе конфигурации по умолчанию Winch Wasmtime приводит к DoS. Отключение страниц охраны перед линейной памятью требуется для возможной утечки до 16 байтов данных хоста. Эта уязвимость зафиксирована в пунктах 36.0.7, 42.0.2 и 43.0.1.

CVE-2026-44216Wasmtime - это время работы для WebAssembly. С 30.0.0 до 36.0.8, 43.0.2 и 44.0.1, логика распределения Wasmtime для таблицы WebAssembly содержала проверенную арифметику, которая паниковала при переполнении. Этот перелив можно спровоцировать и, таким образом, запаниковать, когда выделяется стол с чрезвычайно большим размером. Это возможно с предложением WebAssembly memory64, где столы могут иметь размеры в 64-битном диапазоне, в отличие от предыдущего 32-битного диапазона, который не будет переполняться. Паника возникает при попытке создать очень большой стол, например, при инстанциации модуля или компонента WebAssembly. Эта уязвимость зафиксирована в 36.0.8, 43.0.2 и 44.0.1.

CVE-2026-34946Wasmtime - это время работы для WebAssembly. С 25.0.0 до 36.0.7, 42.0.2 и 43.0.1, компилятор Winch от Wasmtime содержит уязвимость, в которой компиляция инструкции table.fill может привести к панике хоста. Это означает, что действительный гость может быть составлен с Winch, на любой архитектуре, и вызвать у хозяина паниковать. Это представляет собой уязвимость отказа в обслуживании в Wasmtime из-за того, что гости могут вызвать панику. Специфическая проблема заключается в том, что историческая рефакторатура изменила то, как составленные таблицы ссылок на код в таблице.* инструкции. Эта рефакторатура забыла обновить связанные с ним пути кода Winch, что означает, что Winch использовал неправильную схему индексации. Из-за поддержки функции Winch единственная проблема, которая может возникнуть, - это перепутанные столы или используемые несуществующие таблицы, что означает, что гость ограничен паникой хозяина (используя несуществующую таблицу) или выполнением неправильного поведения и модификации неправильного стола. Эта уязвимость зафиксирована в 36.0.7, 42.0.2 и 43.0.1.

CVE-2026-34942Wasmtime - это время работы для WebAssembly. До 24.0.7, 36.0.7, 42.0.2 и 43.0.1 реализация Wasmtime транскодирования струн в utf16 или latin1+utf16 кодировку Wasmtime ненадлежащим образом проверяла выравнивание перераспределенных строк. Это означало, что невыровненные указатели могли быть переданы хозяину для перекодирования, что вызвало бы панику хозяина. Эта паника может возникнуть у злоумышленников, которые передают очень специфические строки по компонентам с определенными адресами. Панические состояния хозяина считаются вектором DoS в Wasmtime, поскольку панические условия контролируются гостем в этой ситуации. Эта уязвимость зафиксирована в пункте 24.0.7, 36.0.7, 42.0.2 и 43.0.1.

CVE-2026-34943Wasmtime - это время работы для WebAssembly. До 24.0.7, 36.0.7, 42.0.2 и 43.0.1 Wasmtime содержит возможную панику, которая может произойти, когда значение модели, набранного флагами, с помощью типа Val. Если биты установлены за пределами набора флагов, модель компонента указывает, что эти биты должны быть проигнорированы, но Wasmtime будет паниковать, когда это значение будет поднято. Эта паника влияет только на реализацию времени подъема в Val, а не при использовании макрофайлов! Это также влияет только на значения, типизированные флагами, которые являются частью интерфейса WIT. Это может быть паникой, контролируемой гостем, внутри хозяина, которую Wasmtime считает вектором DoS. Эта уязвимость зафиксирована в пункте 24.0.7, 36.0.7, 42.0.2 и 43.0.1.

CVE-2022-31104Wasmtime — это автономная среда выполнения для WebAssembly. В уязвимых версиях реализация SIMD для WebAssembly в wasmtime на x86_64 содержала две различные ошибки в понижениях инструкций, реализованных в Cranelift. Реализация SIMD в aarch64 не затрагивается. Ошибки были представлены в инструкциях WebAssembly `i8x16.swizzle` и `select`. Инструкция `select` затрагивается только тогда, когда входные данные имеют тип `v128`. Соответственно затронутые инструкции Cranelift — `swizzle` и `select`. Понижение инструкции `swizzle` в Cranelift ошибочно перезаписывало регистр ввода маски, что могло повредить, например, константное значение. Это означает, что будущие использования той же константы могут видеть другое значение, чем сама константа. Понижение инструкции `select` в Cranelift было реализовано неправильно для векторных типов шириной 128 бит. Когда условие было равно 0, для перемещения правильного ввода в выходные данные инструкции использовалась неправильная инструкция, что означало, что были перемещены только младшие 32 бита, а верхние 96 битов результата остались такими, какими они были ранее в регистре (вместо перемещения ввода). Однако инструкция `select` работала правильно, если условие было ненулевым. Эта ошибка в реализации Wasmtime этих инструкций на x86_64 представляет собой неправильную реализацию указанной семантики этих инструкций в соответствии со спецификацией WebAssembly. Влияние этого безобидно для хостов, запускающих WebAssembly, но представляет собой возможные уязвимости в выполнении гостевой программы. Например, программа WebAssembly может выполнять непреднамеренные переходы или материализовать неверные значения внутри себя, что подвергает программу риску других связанных уязвимостей, которые могут возникнуть из-за неправильных компиляций. Мы выпустили Wasmtime 0.38.1 и cranelift-codegen (и другие связанные крейты cranelift) 0.85.1, которые содержат исправленные реализации этих двух инструкций в Cranelift. Если обновление в данный момент невозможно, вы можете избежать уязвимости, отключив предложение Wasm simd. Кроме того, ошибка присутствует только на хостах x86_64. Другие хосты aarch64 не затрагиваются. Обратите внимание, что хосты s390x еще не реализуют предложение simd и не затрагиваются.

Перейти к вендору →Открыть в каталоге с фильтром по продукту →