Out-of-stack-space DoS in regex code

[corporateshill]

There's a recursion bug in regex handling code

On Ubuntu 16.04.2,

$ python tools/build.py --compile-flag=-m32 --clean --jerry-libc=OFF --system-allocator ON --compile-flag=-ggdb3 --debug --link-lib mcheck

(gdb) shell cat x.js
''.match(/(){70000}/)

(gdb) r
Starting program: /afl/new/jerryscript/build/bin/jerry x.js

Program received signal SIGSEGV, Segmentation fault.
0x0805ed53 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7fe158)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:375
375 ecma_value_t ret_value = ecma_make_simple_value (ECMA_SIMPLE_VALUE_EMPTY);
(gdb) where
#0 0x0805ed53 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7fe158)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:375
#1 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7fe308)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#2 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7fe4b8)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#3 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7fe668)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#4 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7fe818)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#5 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7fe9c8)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#6 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7feb78)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#7 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7fed28)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#8 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7feed8)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#9 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7ff088)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#10 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7ff238)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#11 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7ff3e8)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#12 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7ff598)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987
#13 0x080604c8 in re_match_regexp.lto_priv.197 (re_ctx_p=0xffffd048, bc_p=0x8377f5a "\004\001", str_p=0x8127a6a "", out_str_p=0xff7ff748)
at /afl/new/jerryscript/jerry-core/ecma/operations/ecma-regexp-object.c:987

[LaszloLango]

[wontfix] The RegExp executor works as the ECMA-262 declares. The minimum number of iterations must be satisfied. This issue should be handled by the OS.