While fuzzing the regex module via hongfuzz $ echo D | grep -E "$(printf '(\0|)(\\1\\1)*')" bash: warning: command substitution: ignored null byte in input Segmentation fault (core dumped) ==6453== Process terminating with default action of signal 13 (SIGPIPE) ==6453== at 0x4F4C154: write (write.c:27) ==6453== by 0x4EC71BC: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1203) ==6453== by 0x4EC8F50: new_do_write (fileops.c:457) ==6453== by 0x4EC8F50: _IO_do_write@@GLIBC_2.2.5 (fileops.c:433) ==6453== by 0x4EC6787: _IO_file_sync@@GLIBC_2.2.5 (fileops.c:813) ==6453== by 0x4EBA87C: fflush (iofflush.c:40) ==6453== by 0x10CE73: ??? (in /bin/echo) ==6453== by 0x10C939: ??? (in /bin/echo) ==6453== by 0x10A221: ??? (in /bin/echo) ==6453== by 0x4E7F040: __run_exit_handlers (exit.c:108) ==6453== by 0x4E7F139: exit (exit.c:139) ==6453== by 0x4E5DB9D: (below main) (libc-start.c:344) ==6453== OS: Linux ubuntu 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
The SIGPIPE is spurious and comes from the wrong process. The null byte warning is immaterial as well. This also reproduces the issue: grep -E "$(printf '(|)(\\1\\1)*')" It looks like an infinite recursion in check_dst_limits_calc_pos_1: #0 0x00007f7559c776ad in check_dst_limits_calc_pos_1 ( mctx=mctx@entry=0x7ffee83d11f0, boundaries=boundaries@entry=3, subexp_idx=subexp_idx@entry=0, from_node=5, bkref_idx=bkref_idx@entry=0) at regexec.c:1906 #1 0x00007f7559c7781a in check_dst_limits_calc_pos_1 ( mctx=mctx@entry=0x7ffee83d11f0, boundaries=boundaries@entry=3, subexp_idx=subexp_idx@entry=0, from_node=6, bkref_idx=bkref_idx@entry=0) at regexec.c:1949 #2 0x00007f7559c7781a in check_dst_limits_calc_pos_1 ( mctx=mctx@entry=0x7ffee83d11f0, boundaries=boundaries@entry=3, subexp_idx=subexp_idx@entry=0, from_node=5, bkref_idx=bkref_idx@entry=0) at regexec.c:1949 #3 0x00007f7559c7781a in check_dst_limits_calc_pos_1 ( mctx=mctx@entry=0x7ffee83d11f0, boundaries=boundaries@entry=3, subexp_idx=subexp_idx@entry=0, from_node=6, bkref_idx=bkref_idx@entry=0) at regexec.c:1949 #4 0x00007f7559c7781a in check_dst_limits_calc_pos_1 ( mctx=mctx@entry=0x7ffee83d11f0, boundaries=boundaries@entry=3, subexp_idx=subexp_idx@entry=0, from_node=5, bkref_idx=bkref_idx@entry=0) at regexec.c:1949 #5 0x00007f7559c7781a in check_dst_limits_calc_pos_1 ( mctx=mctx@entry=0x7ffee83d11f0, boundaries=boundaries@entry=3, subexp_idx=subexp_idx@entry=0, from_node=6, bkref_idx=bkref_idx@entry=0) at regexec.c:1949 #6 0x00007f7559c7781a in check_dst_limits_calc_pos_1 ( mctx=mctx@entry=0x7ffee83d11f0, boundaries=boundaries@entry=3, subexp_idx=subexp_idx@entry=0, from_node=5, bkref_idx=bkref_idx@entry=0) at regexec.c:1949 #7 0x00007f7559c7781a in check_dst_limits_calc_pos_1 ( mctx=mctx@entry=0x7ffee83d11f0, boundaries=boundaries@entry=3, subexp_idx=subexp_idx@entry=0, from_node=6, bkref_idx=bkref_idx@entry=0) at regexec.c:1949 Line numbers are as of commit 34a5a1460e9c05d6035bfbde327ab6d45f78958b. Not flagging as a security vulnerability because this needs a crafted pattern.
grep -E "$(printf '(|)(\\1\\1)*')" ==10544== Stack overflow in thread #1: can't grow stack to 0x1ffe801000 ==10544== ==10544== Process terminating with default action of signal 11 (SIGSEGV) ==10544== Access not within mapped region at address 0x1FFE801FF8 ==10544== Stack overflow in thread #1: can't grow stack to 0x1ffe801000 ==10544== at 0x539FC7C: check_dst_limits_calc_pos_1 (regexec.c:1882) ==10544== If you believe this happened as a result of a stack ==10544== overflow in your program's main thread (unlikely but ==10544== possible), you can try to increase the size of the ==10544== main thread stack using the --main-stacksize= flag. ==10544== The main thread stack size used in this run was 8388608. ==10544== Stack overflow in thread #1: can't grow stack to 0x1ffe801000 ==10544== ==10544== Process terminating with default action of signal 11 (SIGSEGV) ==10544== Access not within mapped region at address 0x1FFE801FE8 ==10544== Stack overflow in thread #1: can't grow stack to 0x1ffe801000 ==10544== at 0x4A2A650: _vgnU_freeres (vg_preloaded.c:59) ==10544== If you believe this happened as a result of a stack ==10544== overflow in your program's main thread (unlikely but ==10544== possible), you can try to increase the size of the ==10544== main thread stack using the --main-stacksize= flag. ==10544== The main thread stack size used in this run was 8388608.
A CVE identifier has apparently been assigned to this bug even if it is clearly not a security vulnerability.
Reference: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34141
Florian, please correct me if i am wrong. Reference: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34141 The above issue was found in SED with different testcase. However the bug which i submitted is different, so why we are referring to CVE-2018-20796 ?
(In reply to Dhiraj from comment #5) > Florian, please correct me if i am wrong. > > Reference: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34141 > > The above issue was found in SED with different testcase. However the bug > which i submitted is different, so why we are referring to CVE-2018-20796 ? Sorry, you are right, the bugs are different.
In which way do they differ?