Out-of-bounds memory access on WASM

[Timmmm]

I've compiled rustfmt to WASI but when it tries to format a file (not all files) I get an out-of-bounds access, off the end of memory.

To be honest I'm not very familiar with WASM so I may have done something completely wrong, but anyway... just posting this in case the reason is very obvious. I'll keep investigating (or maybe just disable SIMD if I can figure out how).

Using rustfmt config file /rustfmt.toml for src/lib.rs
Formatting src/attr/doc_comment.rs
Formatting src/attr.rs
Error: failed to run main module `target/wasm32-wasip2/release/rustfmt.wasm`

Caused by:
    0: failed to invoke `run` function
    1: error while executing at wasm backtrace:
           0: 0x2a4e04 - rustfmt-81c1410cf7d4a22e.wasm!bytecount::simd::wasm::chunk_count::h9f78c3718afe1e13
           1: 0x2a50fd - rustfmt-81c1410cf7d4a22e.wasm!bytecount::count::h141829ee0169d2dc
           2: 0xd4a3b - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::push_rewrite_inner::hd7d0efd066b23e28
           3: 0xcbacd - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::push_rewrite::h4e561f75389eedac
           4: 0xd75d1 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::walk_stmts::h3630357a0cf87d89
           5: 0xd7c89 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::walk_stmts::h3630357a0cf87d89
           6: 0xd7c89 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::walk_stmts::h3630357a0cf87d89
           7: 0xd7c89 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::walk_stmts::h3630357a0cf87d89
           8: 0xd7c89 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::walk_stmts::h3630357a0cf87d89
           9: 0xd5dd3 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::visit_block::ha5f3ed27743c3112
          10: 0xda9c9 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::visit_fn::h962286519e1fe4b7
          11: 0xcfef3 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::visit_assoc_item::h092911962d7200da
          12: 0xce59a - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::items::<impl rustfmt_nightly::visitor::FmtVisitor>::visit_impl_items::hd059404252507865
          13: 0x100dfe - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::items::format_impl::ha48263f62e8c273d
          14: 0xdbb1b - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::with_context::h347fc9068f42149d
          15: 0xd3c28 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::visit_item::h30f951fdc95fae96
          16: 0xd1ed2 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::reorder::<impl rustfmt_nightly::visitor::FmtVisitor>::visit_items_with_reordering::h52f45b2617c26736
          17: 0xdc5ae - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::visitor::FmtVisitor::format_separate_mod::h45a3bd9d58646f39
          18: 0x132ad - rustfmt-81c1410cf7d4a22e.wasm!rustfmt_nightly::formatting::format_project::h36c1fcb958268cb9
          19: 0x1f675 - rustfmt-81c1410cf7d4a22e.wasm!scoped_tls::ScopedKey<T>::with::h1f766f4ae004e6e8
          20: 0x1206a - rustfmt-81c1410cf7d4a22e.wasm!rustc_span::create_session_if_not_set_then::h6abdc2a263d1518d
          21: 0xddad - rustfmt-81c1410cf7d4a22e.wasm!rustfmt::format_and_emit_report::h0fc4e345a6330888
          22: 0xd05f - rustfmt-81c1410cf7d4a22e.wasm!rustfmt::execute::h121b2092b11d5c62
          23: 0x9413 - rustfmt-81c1410cf7d4a22e.wasm!rustfmt::main::h84b45e543f42d2d8
          24: 0x26328 - rustfmt-81c1410cf7d4a22e.wasm!std::sys::backtrace::__rust_begin_short_backtrace::h1547f2619d8b6f2e
          25: 0x150b3 - rustfmt-81c1410cf7d4a22e.wasm!std::rt::lang_start::{{closure}}::h2b5c45732efbace8
          26: 0x67f395 - rustfmt-81c1410cf7d4a22e.wasm!std::rt::lang_start_internal::hcce3c2c021d397e1
          27: 0xebab - rustfmt-81c1410cf7d4a22e.wasm!__main_void
          28: 0x6b34 - rustfmt-81c1410cf7d4a22e.wasm!_start
          29: 0x92b29d - wit-component:adapter:wasi_snapshot_preview1!wasi:cli/run@0.2.3#run
    2: memory fault at wasm address 0x14e0020 in linear memory of size 0x14e0000
    3: wasm trap: out of bounds memory access

[Timmmm]

Ah yeah, after reading the code (and talking to ChatGPT a bit!) I'm pretty sure it is a bug.

First we get to simd::wasm::chunk_count() with any input >= 16 bytes.

pub fn count(haystack: &[u8], needle: u8) -> usize {
...
    if haystack.len() >= 16 {
...
        #[cfg(target_arch = "wasm32")]
        {
            unsafe {
                return simd::wasm::chunk_count(haystack, needle);
            }
        }
    }

Then we start reading the haystack:

#[target_feature(enable = "simd128")]
pub unsafe fn chunk_count(haystack: &[u8], needle: u8) -> usize {
...
    while haystack.len() >= offset + 16 * 255 {
..
        // Read 64 * 255 = 16320 bytes from offset.
        for _ in 0..255 {
            let (h1, h2, h3, h4) = u8x16x4_from_offset(haystack, offset);
            count1 = u8x16_sub(count1, u8x16_eq(h1, needles));
            count2 = u8x16_sub(count2, u8x16_eq(h2, needles));
            count3 = u8x16_sub(count3, u8x16_eq(h3, needles));
            count4 = u8x16_sub(count4, u8x16_eq(h4, needles));
            offset += 64;
        }

So there is a length check, but it doesn't seem to be correct. E.g. if haystack.len() is 16*255 = 4080 bytes we enter the loop. But then we actually read 16320 bytes. If you're lucky and not near the end of memory it will work fine so I guess it's a bit random and that's why it wasn't noticed.

I think the fix is just to change it to 64 * 255? I'll try it. I haven't really read the rest of the function to see if it's correct yet either.