2021165 - firefox wasm js-string builtin fromcharcodearray triggers stack oob write via stablewasmarrayobjectelements\<uint16\_t\> std::copy byte/element mismatch

Status: RESOLVED DUPLICATE of bug 1992130

(Core :: JavaScript: WebAssembly, defect, P1)

Description

[Oleh Konko [:1seal]]

Attachment: poc.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36

Steps to reproduce:

version:
trunk/nightly (gecko-dev commit 5836a062726f715fda621338a17b51aff30d0a8c)

what did you do? (steps to reproduce)

1. build a spidermonkey js shell from gecko-dev commit 5836a062726f715fda621338a17b51aff30d0a8c with asan enabled (recommended to make the memory corruption observable).
2. attach poc.zip.
3. reproduce:
   • unzip -q -o poc.zip -d poc && cd poc/poc-F-MOZILLA-FIREFOX-WASM-ARRAY-OOB-001
   • SM_JS=/path/to/js bash ./canonical.sh
   • (negative control) SM_JS=/path/to/js bash ./control.sh
4. if the build requires prefs for these features, run the shell with:
   • --setpref wasm_gc=true --setpref wasm_js_string_builtins=true

Actual results:

asan reports a deterministic stack out-of-bounds write when the fallback path is taken:

• AddressSanitizer: stack-buffer-overflow
• WRITE of size 2
• top frames include js::StableWasmArrayObjectElements<unsigned short>::StableWasmArrayObjectElements(...) and js::wasm::Instance::stringFromCharCodeArray(...)

Expected results:

no out-of-bounds write; fallback path should copy exactly numElements uint16_t elements (not iterate in bytes), and should not copy the inline data header bytes into the element stream.

Comment 1

[Oleh Konko [:1seal]]

Attachment: ADDENDUM

Comment 2

[Oleh Konko [:1seal]]

Attachment: ## summary spidermonkey’s wasm gc inline-storage stabilization helper (`StableWasmArrayObjectElements<T>`) performs a `std::copy` with byte-based iterator arithmetic into an element-typed destination buffer. for `T=uint16_t`, this deterministically wri

Comment 3

[Daniel Veditz [:dveditz]]

https://github.com/mozilla/gecko-dev is archived and has not been updated in eight months. As that archive itself says, use https://github.com/mozilla-firefox/firefox instead. The specific code you reference here no longer exists in the current codebase.

Comment 4

[Daniel Veditz [:dveditz]]

Ryan: you removed this code in bug 2013616, but that was to fix a regression from bug 2005437 in nightly 148. The reporter appears to be testing code from early 142 so if there's a real problem here it might still exist in ESR-140.x also. Does it?

Comment 5

[Ryan Hunt [:rhunt]]

The description of the issue with std::copy is exactly bug 1992130. The fixed code was uplifted to ESR140 [1]. Bug 1992130 lists Fx143 as wontfix, so I'm guessing the reporter testing on Fx142 is just in the gap before it was fixed.

[1] https://searchfox.org/firefox-esr140/rev/cab2d629eb33fb4ff0ede4ef1e49fec9f9a8bad6/js/src/wasm/WasmGcObject.h#548