Add bounds check in VMContinuationStack::initialize for args buffer size by SebTardif · Pull Request #13662 · bytecodealliance/wasmtime

SebTardif · 2026-06-16T00:43:40Z

VMContinuationStack::initialize writes control data and an args buffer at offsets below the top of the continuation stack, but does not verify that the total size fits within the allocated stack region.

The problem

A Wasm module can define a continuation function type with a large number of parameters or return values. When cont.new is executed, the call chain reaches initialize() (stack/unix.rs:226), which computes:

args_data_size = max(param_count, return_count) * size_of::<ValRaw>()

The fixed header occupies 0x40 (64) bytes. If the total control data size (header + args buffer) exceeds the stack allocation, the write loop stores values past the stack region into adjacent memory. With the default 2 MiB stack, this requires 131,069+ params; with a smaller async_stack_size, fewer params suffice (e.g., 800 params on an 8 KiB stack).

Without this fix, the out-of-bounds write hits the guard page and crashes with SIGSEGV. With the fix, a clean error is returned instead.

The fix

Replace the unchecked multiplication with checked_mul + checked_add, returning an error on arithmetic overflow.
Add a bounds check (ensure!(total_control_size <= self.len)) before any writes, so a high-arity function type produces a clean trap instead of a crash.
Change the return type of initialize from () to Result<()> and propagate the error through the stack.rs wrapper and the cont_new caller (which already returns Result).

Test

A regression test (stack_switching_cont_new_high_arity_rejected) creates a function type with 800 i32 params on an 8 KiB continuation stack, verifying that cont.new returns an error instead of crashing. The test skips gracefully on platforms where stack switching is not supported.

Bug origin

Introduced in #10388 ("Stack switching: Infrastructure and runtime support", Frank Emrich, 2025-06-04).

VMContinuationStack::initialize writes control data and an args buffer at offsets below the top of the stack, but did not verify that the total size fits within the allocated stack. A WebAssembly module with a continuation function type with a very large number of parameters or return values could cause writes past the guard page into adjacent memory mappings. This commit adds: - Checked arithmetic (checked_mul + checked_add) for the args buffer size calculation to prevent overflow. - A bounds check ensuring the total control data size (0x40 bytes of fixed header + args buffer) does not exceed the stack allocation. - Propagation of the new Result return type through the stack.rs wrapper and the cont_new caller. The dummy implementation (for unsupported platforms) is updated to match the new signature. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>

Adds a test that creates a continuation function type with 4,500 parameters on a 64 KiB continuation stack, verifying that cont.new returns an error instead of writing past the stack allocation. The test skips gracefully on platforms where stack switching is not supported (e.g., macOS aarch64, Pulley). Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>

alexcrichton · 2026-06-16T17:45:47Z

-            let args_data_size =
-                usize::try_from(args_capacity).unwrap() * std::mem::size_of::<ValRaw>();
+            let args_data_size = usize::try_from(args_capacity)
+                .unwrap()


Since this function now returns Result could this use ? instead of .unwrap()?

Done, replaced all three .unwrap() calls in initialize with ?.

alexcrichton · 2026-06-16T17:47:53Z

+            // Ensure the control data (fixed header + args buffer) fits
+            // within the stack allocation. Without this check, a
+            // high-arity function type could write past the guard page
+            // into adjacent memory.
+            let total_control_size = 0x40 + args_data_size;


Could this avoid the dance here of adding/subtracting/adding 0x40 by setting the original computation to total_control_size, then calculating args_data_size by subtracing 0x40 from that?

Good call. Now computes total_control_size directly from the checked arithmetic, then derives args_data_size = total_control_size - 0x40. Also replaced tos.sub(0x40 + args_data_size) with tos.sub(total_control_size) in the to_store array for consistency.

- Compute total_control_size directly instead of the add/subtract/add dance with 0x40 - Replace .unwrap() with ? on usize::try_from calls since initialize now returns Result - Add assert!(!cfg!(target_arch = "x86_64")) to the test skip guard so x86_64 never silently skips the test Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>

alexcrichton

Thanks! Happy to merge once CI is green

Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>

alexcrichton · 2026-06-16T21:13:57Z

+
+    let Ok(engine) = Engine::new(&config) else {
+        // Stack switching is not supported on all platforms; skip gracefully.
+        assert!(!cfg!(target_arch = "x86_64"));


Ah, sorry, this'll need adjusting to:

assert!(!(cfg!(target_arch = "x86_64") && cfg!(unix)));

Done, updated to check both conditions.

Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>

Fix the bounds check in VMContinuationStack::initialize to compare against usable stack space rather than total allocation size. Prior to bytecodealliance#13662, initialize() had no bounds check at all, so a high-arity function type (e.g. 600 params on an 8192-byte stack) would unconditionally write control data into the guard page and segfault. PR bytecodealliance#13662 added a bounds check, but compared against self.len which for Mmap allocations includes the guard page. This meant the 600-param case still slipped through: 9664 <= 12288 passed the check, but the write still landed in the non-writable guard page. This fix subtracts the guard page size for Mmap allocations so the check reflects the actual usable stack space. Custom allocations are unaffected since their len does not include a guard page. Adds a regression test matching the exact scenario from bytecodealliance#13703 (600 params on an 8192-byte stack). Closes bytecodealliance#13703 Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>

…iance#13704) Fix the bounds check in VMContinuationStack::initialize to compare against usable stack space rather than total allocation size. Prior to bytecodealliance#13662, initialize() had no bounds check at all, so a high-arity function type (e.g. 600 params on an 8192-byte stack) would unconditionally write control data into the guard page and segfault. PR bytecodealliance#13662 added a bounds check, but compared against self.len which for Mmap allocations includes the guard page. This meant the 600-param case still slipped through: 9664 <= 12288 passed the check, but the write still landed in the non-writable guard page. This fix subtracts the guard page size for Mmap allocations so the check reflects the actual usable stack space. Custom allocations are unaffected since their len does not include a guard page. Adds a regression test matching the exact scenario from bytecodealliance#13703 (600 params on an 8192-byte stack). Closes bytecodealliance#13703 Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>

SebTardif requested a review from a team as a code owner June 16, 2026 00:43

SebTardif requested review from pchickey and removed request for a team June 16, 2026 00:43

SebTardif force-pushed the fix-stack-switching-initialize-bounds-check branch from 2b8f887 to c329b8f Compare June 16, 2026 01:00

SebTardif added 2 commits June 15, 2026 18:11

SebTardif force-pushed the fix-stack-switching-initialize-bounds-check branch from c329b8f to 876e35c Compare June 16, 2026 01:34

github-actions Bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Jun 16, 2026

alexcrichton reviewed Jun 16, 2026

View reviewed changes

alexcrichton requested review from alexcrichton and removed request for pchickey June 16, 2026 17:50

alexcrichton approved these changes Jun 16, 2026

View reviewed changes

Fix rustfmt formatting

d1fc00b

Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>

alexcrichton enabled auto-merge June 16, 2026 20:11

alexcrichton added this pull request to the merge queue Jun 16, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jun 16, 2026

alexcrichton reviewed Jun 16, 2026

View reviewed changes

Fix assert to cover both x86_64 and unix

c7ed396

Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>

alexcrichton added this pull request to the merge queue Jun 16, 2026

Merged via the queue into bytecodealliance:main with commit 2d2718f Jun 16, 2026
51 checks passed

alexcrichton mentioned this pull request Jun 22, 2026

Stack-switching crash with just enough parameters #13703

Closed

SebTardif mentioned this pull request Jun 22, 2026

Exclude guard page from stack bounds check in initialize #13704

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add bounds check in VMContinuationStack::initialize for args buffer size#13662

Add bounds check in VMContinuationStack::initialize for args buffer size#13662
alexcrichton merged 5 commits into
bytecodealliance:mainfrom
SebTardif:fix-stack-switching-initialize-bounds-check

SebTardif commented Jun 16, 2026 •

edited by alexcrichton

Loading

Uh oh!

alexcrichton Jun 16, 2026

Uh oh!

SebTardif Jun 16, 2026

Uh oh!

alexcrichton Jun 16, 2026

Uh oh!

SebTardif Jun 16, 2026

Uh oh!

Uh oh!

alexcrichton left a comment

Uh oh!

Uh oh!

alexcrichton Jun 16, 2026

Uh oh!

SebTardif Jun 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

SebTardif commented Jun 16, 2026 • edited by alexcrichton Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The problem

The fix

Test

Bug origin

Uh oh!

alexcrichton Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

SebTardif Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

alexcrichton Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

SebTardif Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alexcrichton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alexcrichton Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

SebTardif Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

SebTardif commented Jun 16, 2026 •

edited by alexcrichton

Loading