Commit d99e559
authored
wasmparser: Relocation range end can wrap on 32-bit targets (#2497)
* wasmparser: Relocation range end can wrap on 32-bit targets
RelocationEntry::relocation_range() derived a Range<usize> from
untrusted relocation offsets using `self.offset as usize` and
start + self.ty.extent().
On 32-bit targets, large parsed offsets can overflow the end computation,
causing a debug-build panic or release-build wraparound instead of
rejection.
That can be reproduced with a 30-byte wasm module consisting of a header
and a single `reloc.CODE` custom section with one entry:
| Field | Value | Encoding |
|--------|---------------------------|--------------------------------|
| type | `FunctionIndexLeb` (0x00) | extent = 5, no addend |
| offset | `0xFFFF_FFFC` | LEB128: `FC FF FF FF 0F` |
| index | 0 | LEB128: `00` |
$ cargo build -p wasmparser --example reloc_overflow --target wasm32-wasip1
$ wasmtime target/wasm32-wasip1/debug/examples/reloc_overflow.wasm
parsed: type=FunctionIndexLeb, offset=0xFFFFFFFC, extent=5
thread 'main' panicked at crates/wasmparser/src/readers/core/reloc.rs:246:33:
attempt to add with overflow
In release mode the panic becomes a silent wraparound:
$ cargo build --release -p wasmparser --example reloc_overflow --target wasm32-wasip1
$ wasmtime target/wasm32-wasip1/release/examples/reloc_overflow.wasm
parsed: type=FunctionIndexLeb, offset=0xFFFFFFFC, extent=5
relocation_range() = 0xFFFFFFFC..0x1
BUG: range end < start due to overflow
Autonomously found by https://swival.dev /scan
* FOrmat1 parent 0285a46 commit d99e559
1 file changed
Lines changed: 6 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
242 | 242 | | |
243 | 243 | | |
244 | 244 | | |
245 | | - | |
246 | | - | |
| 245 | + | |
| 246 | + | |
| 247 | + | |
| 248 | + | |
| 249 | + | |
| 250 | + | |
247 | 251 | | |
248 | 252 | | |
249 | 253 | | |
| |||
0 commit comments