ASAN violation in embind fromWireType for std::string #11598
Description
This does not cause problem when ASAN is not enabled, but makes ASAN unusable since it always halt on this violation before actual problem can be detected.
Here's a minimal re-pro code:
// asan.cc
#include <emscripten/bind.h>
void call_js(emscripten::val v) {
std::string p("hello");
v(p);
}
EMSCRIPTEN_BINDINGS(m) {
function("callback", &call_js);
}
With a pre-js to invoke the bindings
// asan-pre.js
Module.onRuntimeInitialized = () => {
Module.callback((p) => { console.log("from wasm:", p); });
};
Runs fine without ASAN:
$ em++ --bind --pre-js asan-pre.js asan.cc -o asan.js && node asan.js
from wasm: hello
ASAN violation:
$ em++ --bind --pre-js asan-pre.js -fsanitize=address -s INITIAL_MEMORY=67108864 asan.cc -o asan.js && node asan.js
=================================================================
==42==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x037007b9 at pc 0x000275db bp 0x02968e20 sp 0x02968e2c
READ of size 1 at 0x037007b9 thread T0
#0 0x275db in wasm-function[1040]+0x275db (/Users/jiulongw/tmp/asan.wasm+0x275db)
#1 0x800018fd in Module._asan_c_load_1u /Users/jiulongw/tmp/asan.js:6397:41
0x037007b9 is located 0 bytes to the right of 9-byte region [0x037007b0,0x037007b9)
allocated by thread T0 here:
#0 0xfd2d in wasm-function[584]+0xfd2d (/Users/jiulongw/tmp/asan.wasm+0xfd2d)
#1 0x235a in wasm-function[77]+0x235a (/Users/jiulongw/tmp/asan.wasm+0x235a)
#2 0x2088 in wasm-function[71]+0x2088 (/Users/jiulongw/tmp/asan.wasm+0x2088)
#3 0x17fa in wasm-function[59]+0x17fa (/Users/jiulongw/tmp/asan.wasm+0x17fa)
#4 0x1466 in wasm-function[54]+0x1466 (/Users/jiulongw/tmp/asan.wasm+0x1466)
#5 0x11a8 in wasm-function[52]+0x11a8 (/Users/jiulongw/tmp/asan.wasm+0x11a8)
#6 0x1ccd in wasm-function[63]+0x1ccd (/Users/jiulongw/tmp/asan.wasm+0x1ccd)
#7 0x285cf in wasm-function[1066]+0x285cf (/Users/jiulongw/tmp/asan.wasm+0x285cf)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/Users/jiulongw/tmp/asan.wasm+0x275da) in wasm-function[1040]+0x275da
Shadow bytes around the buggy address:
0x006e00a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x006e00b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x006e00c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x006e00d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x006e00e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x006e00f0: fa fa fa fa fa fa 00[01]fa fa fa fa fa fa fa fa
0x006e0100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x006e0110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x006e0120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x006e0130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x006e0140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==42==ABORTING
It seems to be related to #10844 where length is used instead of \0 to detected string boundaries.