An SEGV issue detected when compiled with UBSAN
See original GitHub issueDuktape revision
Commit: 1a1b17ef
Version: 2.99.99
Build environment
Ubuntu 18.04.5 LTS (Linux 5.4.0-44-generic x86_64)
Build steps
make && make clean
make build/duk-sanitize-clang
Test case
poc.js
function JSEtest() {
var src = [];
var i;
src.push('(function test() {');
for (i = 0; i < 1e4; i++) {
src.push('var x' + i + ' = ' + i + ';');
}
src.push('var arguments = test(); return "dummy"; })');
src = src.join('');
var f = eval(src)(src);
try {
f();
} catch (e) {
print(e.name + ': ' + e.message);
}
print('still here');
}
try {
JSEtest();
} catch (e) {
print(e.stack || e);
}
Execution & Output
$ ./duktape/build/duk-sanitize-clang poc.js
==6822==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x7f704fc22000 (pc 0x0000004368e8 bp 0x7f704fc0d901 sp 0x7fffce632cc0 T6822)
==6822==The signal is caused by a READ memory access.
#0 0x4368e7 in duk_push_tval /duktape/duk_api_stack.c:4314:29
#1 0x4f31ff in duk_js_close_environment_record /duktape/duk_js_var.c:724:3
#2 0x4f2913 in duk__activation_unwind_nofree_norz /duktape/duk_hthread_stacks.c:278:3
#3 0x4efd8f in duk_hthread_activation_unwind_norz /duktape/duk_hthread_stacks.c:315:2
#4 0x51f4f7 in duk__handle_longjmp /duktape/duk_js_executor.c:1437:4
#5 0x514d3f in duk__handle_executor_error /duktape/duk_js_executor.c:2900:11
#6 0x4efa37 in duk_js_execute_bytecode /duktape/duk_js_executor.c:3007:4
#7 0x4ea4ab in duk__handle_call_raw /duktape/duk_js_call.c:2242:3
#8 0x524b59 in wrapped_compile_execute /duktape/examples/cmdline/duk_cmdline.c:304:2
#9 0x520d77 in duk__handle_safe_call_inner /duktape/duk_js_call.c:2467:7
#10 0x42d5b6 in duk_handle_safe_call /duktape/duk_js_call.c:2713:3
#11 0x523ff4 in handle_fh /duktape/examples/cmdline/duk_cmdline.c:637:7
#12 0x523e4a in handle_file /duktape/examples/cmdline/duk_cmdline.c:696:11
#13 0x52370c in main /duktape/examples/cmdline/duk_cmdline.c:1653:7
#14 0x7f704ff84bf6 in __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
#15 0x404219 in _start (/duktape/build/duk-sanitize-clang+0x404219)
UndefinedBehaviorSanitizer can not provide additional info.
==6822==ABORTING
Execution without ASAN
$ ./duktape/build/duk poc.js
[1] 57011 segmentation fault /duktape/build/duk poc.js
Issue Analytics
- State:
- Created 2 years ago
- Comments:10 (7 by maintainers)
Top Results From Across the Web
CVE-2021-46322 - CVE.report
Duktape v2.99.99 was discovered to contain a SEGV vulnerability via the component ... An SEGV issue detected when compiled with UBSAN · Issue...
Read more >Segmentation fault on gcc caused by lambda wrapper over ...
I found bug #71386 which looks related to the issue here. ... 0x7d6b45 symbol_table::compile() ... 0x7d8616 symbol_table::compile() ...
Read more >69517 – SEGV on a VLA with excess initializer elements
Continuing with my testing of VLAs in G++ (see bug 69516, bug 69496, and bug 69509), I discovered another problem. When compiled with...
Read more >Aquantia GbE LAN driver causes UBSAN error during kernel ...
The undefined behaviour sanitiser picks up an array-index-out-of-bounds in the aquantia atlantic driver. The NIC is (I think) built into my ...
Read more >Integer Overflow or Wraparound vulnerability found in fast_obj
Whilst experimenting with the test code built from commit d97389 with Clang 11 (+UBSan) on Ubuntu 20.04.2 LTS, we discovered an OBJ file ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

@ddillard It affects 2.x at least so there will be a fix in v2-maintenance.
I think I found the root cause: when
argumentsexists call handling sets up the necessary environment record and “varmap” before the call (normally it is delayed if/until needed). That “varmap” will reference register numbers that don’t yet exist at the time that varmap setup is done. The very next step is to resize (grow) the valstack for the call - but if that fails, the “varmap” will reference out of value stack offsets when the partially complete activation is unwound.The fix might be to grow the value stack before setting up the env record, I’m trying to see if that works in a straightforward manner without other issues.