| Summary: | regexec: Infinite recursion in check_dst_limits_calc_pos_1 | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Dhiraj <mishra.dhiraj95> |
| Component: | regex | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | carlos, drepper.fsp, fweimer |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
|
Description
Dhiraj
2019-02-26 06:24:20 UTC
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. 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? |