WasmEdge 0.17.2-alpha.1 закрила помилки меж пам’яті та AOT

WasmEdge 0.17.2-alpha.1 закриває серію помилок на межі завантажувача, AOT-компіляції та виконання WebAssembly: у релізі додано перевірки меж для memory64, очищення застарілих обробників винятків і захист від запису поза межами пам’яті в try_table. Версія має статус alpha, тому її варто розглядати як ранню перевірку майбутнього виправлення, а не як автоматичну заміну стабільного runtime.

Завантажувач відокремив AOT від звичайного режиму

Native shared-library WASM тепер завантажується лише під час AOT-запуску. Це уточнює межу між байткодом WebAssembly та артефактом, який уже перетворено на нативну бібліотеку. Якщо runtime намагається трактувати такий файл у неправильному режимі, результат може коливатися від незрозумілої помилки до небезпечної інтерпретації структури.

Окреме виправлення перевіряє зміщення символів у custom section AOT-файлу. Перевірка меж потрібна до того, як значення використовується для доступу до буфера: недостатньо сподіватися, що артефакт створено довіреним компілятором, адже серверні платформи часто приймають модулі від різних команд або користувачів.

Виконавець закрив шлях до out-of-bounds запису

У гілках try_table runtime тепер прибирає застарілі exception handlers під час переходу. За release notes, це зупиняє запис поза дозволеними межами. Також catch_all в інтерпретаторі очищує payload винятку, щоб дані попереднього exception не переживали обробку та не впливали на наступний стан.

Ще одне виправлення стосується continuation для return_call під час tail call до host-функції. Tail calls економлять стек, але змінюють порядок повернення керування. Помилка в continuation особливо неприємна на межі sandbox і host API, де runtime має точно відновити контекст виклику та не залишити старі фрейми.

Memory64 і компонентна модель

AOT-шлях отримав перевірку меж для завантажень і записів memory64. Розширений 64-бітний адресний простір потрібен модулям із великими обсягами пам’яті, але водночас збільшує ціну помилки у перетворенні типів, переповненні або розрахунку кінцевої адреси. Перевірка має відбуватися до нативної операції, незалежно від того, які гарантії вже дав валідатор.

Для Component Model виконавець тепер розширює простір індексів під час експорту так само, як цього очікує валідатор. Розбіжність між validation і execution — класичне джерело runtime-збоїв: модуль проходить попередню перевірку, але потім інша частина системи інтерпретує його структуру за відмінними правилами.

Для операторів: якщо WasmEdge запускає недовірені модулі, виправлення меж пам’яті мають високий пріоритет для тестування. Але alpha-збірку спочатку слід прогнати у staging із fuzz-корпусом, реальними AOT-артефактами й негативними тестами.

Що перевірити перед оновленням

• AOT і interpreter мають пройти однакові функціональні тести.
• Перевірте модулі з exceptions, tail calls, memory64 і component exports.
• Відтворіть поточні обмеження sandbox, host permissions і файлового доступу.
• Не використовуйте alpha у production без оцінки ризику регресій та плану швидкого відкату.

Реліз також вимагає OpenCV 5 для плагіна opencvmini на macOS arm64 і доповнює OSS-Fuzz драйвер властивістю Component Model. Це важливо для покриття нових структур автоматичним пошуком помилок, але не доводить відсутності інших уразливостей.

Джерело та права

Матеріал є самостійним українським переказом release notes WasmEdge 0.17.2-alpha.1 від 27 серпня 2026 року. Репозиторій поширюється за Apache License 2.0. Редакція не класифікує перелічені помилки як окремі CVE, оскільки такого твердження немає у першоджерелі. Перекладено, адаптовано й доповнено редакцією «Бібліотеки програміста».