Out-of-Memory Program Abort in wabt::interp::Table::Grow() about wabt HOT 2 CLOSED

I tried running this myself and didn't hit the OOM, but I do see the following right before execution traps on an out-of-bounds table access:

000232 func[7]:
 000233: 02 7c                      | local[3..4] type=f64
 000235: 05 7d                      | local[5..9] type=f32
 000237: 01 7b                      | local[10] type=v128
 000239: 02 7f                      | local[11..12] type=i32
 00023b: 01 70                      | local[13] type=funcref
 00023d: 02 40                      | block
 00023f: 02 40                      |   block
 000241: 42 96 cb 93 d2 97 a2 d5 87 |     i64.const -3094160885426100842
 00024a: 55                         | 
 00024b: 10 03                      |     call 3 <i64.no_fold_f64_u>
 00024d: d0 6f                      |     ref.null extern
 00024f: 41 bc e2 f1 fe 7a          |     i32.const 2950459708
 000255: fc 0f 01                   |     table.grow 1             <------------- Grow table by ~3 billion entries
 000258: 11 06 00                   |     call_indirect 6 0        <------------- Trap with oob table access

Adding the entries from that table.grow instruction will allocate about

2950459708 * 8 = 23603677664 = 0x57EE389E0 bytes

which is pretty close to the amount you see in the failed allocation. So I assume your setup just isn't allowing WSL to allocate that much?

Anyway, there's nothing in the spec that prevents a table from growing this large, so it seems perfectly reasonable for wasm-interp to handle the request. I'd think a user that's concerned about possible DOS attacks would check Wasms to ensure tables and memories have a reasonable maximum size (or modify them to add maximum sizes) before executing.

from wabt.

I tried running this myself and didn't hit the OOM, but I do see the following right before execution traps on an out-of-bounds table access:

000232 func[7]:
 000233: 02 7c                      | local[3..4] type=f64
 000235: 05 7d                      | local[5..9] type=f32
 000237: 01 7b                      | local[10] type=v128
 000239: 02 7f                      | local[11..12] type=i32
 00023b: 01 70                      | local[13] type=funcref
 00023d: 02 40                      | block
 00023f: 02 40                      |   block
 000241: 42 96 cb 93 d2 97 a2 d5 87 |     i64.const -3094160885426100842
 00024a: 55                         | 
 00024b: 10 03                      |     call 3 <i64.no_fold_f64_u>
 00024d: d0 6f                      |     ref.null extern
 00024f: 41 bc e2 f1 fe 7a          |     i32.const 2950459708
 000255: fc 0f 01                   |     table.grow 1             <------------- Grow table by ~3 billion entries
 000258: 11 06 00                   |     call_indirect 6 0        <------------- Trap with oob table access

Adding the entries from that table.grow instruction will allocate about

2950459708 * 8 = 23603677664 = 0x57EE389E0 bytes

which is pretty close to the amount you see in the failed allocation. So I assume your setup just isn't allowing WSL to allocate that much?

Anyway, there's nothing in the spec that prevents a table from growing this large, so it seems perfectly reasonable for wasm-interp to handle the request. I'd think a user that's concerned about possible DOS attacks would check Wasms to ensure tables and memories have a reasonable maximum size (or modify them to add maximum sizes) before executing.

Thanks for your reply @adamrk, that's a fair point. I shall not consider this kind of issue as bug 🤔 .

from wabt.