Bug 24269 (CVE-2018-20796) - regexec: Infinite recursion in check_dst_limits_calc_pos_1
Summary: regexec: Infinite recursion in check_dst_limits_calc_pos_1
Status: UNCONFIRMED
Alias: CVE-2018-20796
Product: glibc
Classification: Unclassified
Component: regex (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-26 06:24 UTC by Dhiraj
Modified: 2019-03-21 08:26 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dhiraj 2019-02-26 06:24:20 UTC
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
Comment 1 Florian Weimer 2019-02-26 10:23: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.
Comment 2 Dhiraj 2019-02-26 10:46:52 UTC
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.
Comment 3 Florian Weimer 2019-02-26 11:01:46 UTC
A CVE identifier has apparently been assigned to this bug even if it is clearly not a security vulnerability.
Comment 4 Florian Weimer 2019-02-26 11:04:18 UTC
Reference: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34141
Comment 5 Dhiraj 2019-02-26 11:18:38 UTC
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 ?
Comment 6 Florian Weimer 2019-02-26 11:49:39 UTC
(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.
Comment 7 Andreas Schwab 2019-03-05 10:29:45 UTC
In which way do they differ?