wasmtime / issue #10179 Memory with inline data segment f... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #10179 Memory with inline data segment f...

Wasmtime GitHub notifications bot (Feb 04 2025 at 12:48):

While implementing the custom-page-sizes proposal in Wasmi I encountered this failing test case in the official Wasm spectest mirror:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "size") (result i32)
    memory.size)
  (func (export "grow") (param i32) (result i32)
    (memory.grow (local.get 0)))
  (func (export "load") (param i32) (result i32)
    (i32.load8_u (local.get 0)))
)
(Link: https://github.com/WebAssembly/testsuite/blob/main/proposals/custom-page-sizes/custom-page-sizes.wast#L116)

Namely, (memory (pagesize 1) (data "xyz")) is a memory declaration with an inline data segment. The Wasm spec says the following about this:

A data segment can be given inline with a memory definition, in which case its offset is and the limits of the memory type are inferred from the length of the data, rounded up to page size:

(Source: https://webassembly.github.io/spec/core/text/modules.html#text-mem-abbrev)

However, i distilled my own test case:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "hello"))
)
Ran wasm-tools parse test-case.wat -o test-case.wasm and ran both Wasmi and Wasmtime with it which both crashed during module instantiation with memory out of bounds.

I re-converted the test-case.wasm back to .wat and saw the following:
(module
  (type (;0;) (func))
  (memory (;0;) 1 1 (pagesize 0x1))
  (export "hello" (func 0))
  (func (;0;) (type 0))
  (data (;0;) (i32.const 0) "xyz")
)
Thus we clearly see that memory has minimum and maximum limits of 1 which is incorrect and should be 3 instead.
I am not sure where exactly the error is originating but since both Wasmi and Wasmtime are affected it might be in the wasmparser crate.
Please move this issue if the exact source of the problem is located.

Wasmtime GitHub notifications bot (Feb 04 2025 at 12:49):

Robbepop edited issue #10179:

While implementing the custom-page-sizes proposal in Wasmi I encountered this failing test case in the official Wasm spectest mirror:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "size") (result i32)
    memory.size)
  (func (export "grow") (param i32) (result i32)
    (memory.grow (local.get 0)))
  (func (export "load") (param i32) (result i32)
    (i32.load8_u (local.get 0)))
)
(Link: https://github.com/WebAssembly/testsuite/blob/main/proposals/custom-page-sizes/custom-page-sizes.wast#L116)

Namely, (memory (pagesize 1) (data "xyz")) is a memory declaration with an inline data segment. The Wasm spec says the following about this:

A data segment can be given inline with a memory definition, in which case its offset is and the limits of the memory type are inferred from the length of the data, rounded up to page size:

(Source: https://webassembly.github.io/spec/core/text/modules.html#text-mem-abbrev)

However, i distilled my own test case:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "hello"))
)
Ran wasm-tools parse test-case.wat -o test-case.wasm and ran both Wasmi and Wasmtime with it which both crashed during module instantiation with memory out of bounds.

I re-converted the test-case.wasm back to .wat and saw the following:
(module
  (type (;0;) (func))
  (memory (;0;) 1 1 (pagesize 0x1))
  (export "hello" (func 0))
  (func (;0;) (type 0))
  (data (;0;) (i32.const 0) "xyz")
)
Thus we clearly see that memory has minimum and maximum limits of 1 which is incorrect and should be 3 instead.
I am not sure where exactly the error is originating but since both Wasmi and Wasmtime are affected it might be in the wast crate.
Please move this issue if the exact source of the problem is located.

Wasmtime GitHub notifications bot (Feb 04 2025 at 12:50):

Robbepop edited issue #10179:

While implementing the custom-page-sizes proposal in Wasmi I encountered this failing test case in the official Wasm spectest mirror:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "size") (result i32)
    memory.size)
  (func (export "grow") (param i32) (result i32)
    (memory.grow (local.get 0)))
  (func (export "load") (param i32) (result i32)
    (i32.load8_u (local.get 0)))
)
(Link: https://github.com/WebAssembly/testsuite/blob/main/proposals/custom-page-sizes/custom-page-sizes.wast#L116)

Namely, (memory (pagesize 1) (data "xyz")) is a memory declaration with an inline data segment. The Wasm spec says the following about this:

A data segment can be given inline with a memory definition, in which case its offset is and the limits of the memory type are inferred from the length of the data, rounded up to page size:

(Source: https://webassembly.github.io/spec/core/text/modules.html#text-mem-abbrev)

However, i distilled my own test case:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "hello"))
)
Ran wasm-tools parse test-case.wat -o test-case.wasm and ran both Wasmi and Wasmtime with it which both crashed during module instantiation with memory out of bounds.

I re-converted the test-case.wasm back to .wat and saw the following:
(module
  (type (;0;) (func))
  (memory (;0;) 1 1 (pagesize 0x1))
  (export "hello" (func 0))
  (func (;0;) (type 0))
  (data (;0;) (i32.const 0) "xyz")
)
Thus we clearly see that memory has minimum and maximum limits of 1 which is incorrect and should be 3 instead.
I am not sure where exactly the error is originating but since both Wasmi and Wasmtime are affected it might be in the wast crate.
Please move this issue if the exact source of the problem is located.

If I manually replace (memory (;0;) 1 1 (pagesize 0x1)) with the correct limits of (memory (;0;) 3 3 (pagesize 0x1)) both Wasmi and Wasmtime no longer crash.

Wasmtime GitHub notifications bot (Feb 04 2025 at 12:51):

Robbepop edited issue #10179:

While implementing the custom-page-sizes proposal in Wasmi I encountered this failing test case in the official Wasm spectest mirror:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "size") (result i32)
    memory.size)
  (func (export "grow") (param i32) (result i32)
    (memory.grow (local.get 0)))
  (func (export "load") (param i32) (result i32)
    (i32.load8_u (local.get 0)))
)
(Link: https://github.com/WebAssembly/testsuite/blob/main/proposals/custom-page-sizes/custom-page-sizes.wast#L116)

Namely, (memory (pagesize 1) (data "xyz")) is a memory declaration with an inline data segment. The Wasm spec says the following about this:

A data segment can be given inline with a memory definition, in which case its offset is and the limits of the memory type are inferred from the length of the data, rounded up to page size:

(Source: https://webassembly.github.io/spec/core/text/modules.html#text-mem-abbrev)

However, i distilled my own test case:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "hello"))
)
Ran wasm-tools parse test-case.wat -o test-case.wasm and ran both Wasmi and Wasmtime with it which both crashed during module instantiation with memory out of bounds.

I re-converted the test-case.wasm back to .wat and saw the following:
(module
  (type (;0;) (func))
  (memory (;0;) 1 1 (pagesize 0x1))
  (export "hello" (func 0))
  (func (;0;) (type 0))
  (data (;0;) (i32.const 0) "xyz")
)
Thus we clearly see that memory has minimum and maximum limits of 1 which is incorrect and should be 3 instead.
I am not sure where exactly the error is originating but since both Wasmi and Wasmtime are affected it might be in the wast crate.
If I manually replace (memory (;0;) 1 1 (pagesize 0x1)) with the correct limits of (memory (;0;) 3 3 (pagesize 0x1)) both Wasmi and Wasmtime no longer crash.

Please move this issue if the exact source of the problem is located.

Wasmtime GitHub notifications bot (Feb 04 2025 at 12:51):

Robbepop edited issue #10179:

While implementing the custom-page-sizes proposal in Wasmi I encountered this failing test case in the official Wasm spectest mirror:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "size") (result i32)
    memory.size)
  (func (export "grow") (param i32) (result i32)
    (memory.grow (local.get 0)))
  (func (export "load") (param i32) (result i32)
    (i32.load8_u (local.get 0)))
)
(Link: https://github.com/WebAssembly/testsuite/blob/main/proposals/custom-page-sizes/custom-page-sizes.wast#L116)

Namely, (memory (pagesize 1) (data "xyz")) is a memory declaration with an inline data segment. The Wasm spec says the following about this:

A data segment can be given inline with a memory definition, in which case its offset is and the limits of the memory type are inferred from the length of the data, rounded up to page size:

(Source: https://webassembly.github.io/spec/core/text/modules.html#text-mem-abbrev)

However, i distilled my own test case:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "hello"))
)
Ran wasm-tools parse test-case.wat -o test-case.wasm and ran both Wasmi and Wasmtime with it which both crashed during module instantiation with memory out of bounds.

I re-converted the test-case.wasm back to .wat and saw the following:
(module
  (type (;0;) (func))
  (memory (;0;) 1 1 (pagesize 0x1))
  (export "hello" (func 0))
  (func (;0;) (type 0))
  (data (;0;) (i32.const 0) "xyz")
)
We clearly see that memory has minimum and maximum limits of 1 which is incorrect and should be 3 instead.
I am not sure where exactly the error is originating but since both Wasmi and Wasmtime are affected it might be in the wast crate.

If I manually replace (memory (;0;) 1 1 (pagesize 0x1)) with the correct limits of (memory (;0;) 3 3 (pagesize 0x1)) both Wasmi and Wasmtime no longer crash.

Please move this issue if the exact source of the problem is located.

Wasmtime GitHub notifications bot (Feb 04 2025 at 13:43):

Robbepop commented on issue #10179:

I located the bug here:
https://github.com/bytecodealliance/wasm-tools/blob/main/crates/wast/src/core/resolve/deinline_import_export.rs#L57

Namely, this line of code is using default_page_size instead of the page_size_log2 field that has been provided above for the calculation of number of pages.
let pages = (len + default_page_size() - 1) / default_page_size();

Wasmtime GitHub notifications bot (Feb 04 2025 at 13:52):

alexcrichton transferred issue #10179:

While implementing the custom-page-sizes proposal in Wasmi I encountered this failing test case in the official Wasm spectest mirror:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "size") (result i32)
    memory.size)
  (func (export "grow") (param i32) (result i32)
    (memory.grow (local.get 0)))
  (func (export "load") (param i32) (result i32)
    (i32.load8_u (local.get 0)))
)
(Link: https://github.com/WebAssembly/testsuite/blob/main/proposals/custom-page-sizes/custom-page-sizes.wast#L116)

Namely, (memory (pagesize 1) (data "xyz")) is a memory declaration with an inline data segment. The Wasm spec says the following about this:

A data segment can be given inline with a memory definition, in which case its offset is and the limits of the memory type are inferred from the length of the data, rounded up to page size:

(Source: https://webassembly.github.io/spec/core/text/modules.html#text-mem-abbrev)

However, i distilled my own test case:
(module
  (memory (pagesize 1) (data "xyz"))
  (func (export "hello"))
)
Ran wasm-tools parse test-case.wat -o test-case.wasm and ran both Wasmi and Wasmtime with it which both crashed during module instantiation with memory out of bounds.

I re-converted the test-case.wasm back to .wat and saw the following:
(module
  (type (;0;) (func))
  (memory (;0;) 1 1 (pagesize 0x1))
  (export "hello" (func 0))
  (func (;0;) (type 0))
  (data (;0;) (i32.const 0) "xyz")
)
We clearly see that memory has minimum and maximum limits of 1 which is incorrect and should be 3 instead.
I am not sure where exactly the error is originating but since both Wasmi and Wasmtime are affected it might be in the wast crate.

If I manually replace (memory (;0;) 1 1 (pagesize 0x1)) with the correct limits of (memory (;0;) 3 3 (pagesize 0x1)) both Wasmi and Wasmtime no longer crash.

Please move this issue if the exact source of the problem is located.

Last updated: Dec 06 2025 at 06:05 UTC