This is the mail archive of the glibc-bugs-regex@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug regex/18986] New: ERE '0|()0|\1|0' causes regexec undefined behavior


https://sourceware.org/bugzilla/show_bug.cgi?id=18986

            Bug ID: 18986
           Summary: ERE '0|()0|\1|0' causes regexec undefined behavior
           Product: glibc
           Version: 2.22
            Status: NEW
          Severity: normal
          Priority: P2
         Component: regex
          Assignee: unassigned at sourceware dot org
          Reporter: eggert at gnu dot org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---
             Flags: security+

Created attachment 8621
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8621&action=edit
Test program illustrating the bug.

This bug report was inspired by an assertion failure in GNU grep:

http://bugs.gnu.org/21513

I tracked it down to undefined behavior in glibc.  Sometimes the behavior
causes a core dump, sometimes the wrong answer, sometimes the right answer.  I
will attach a C program that illustrates the problem for me: compile and run
it, and typically it outputs "match (incorrect)"; it should output either
""regcomp returns REG_ESUBREG (arguably correct)" or "no match (arguably
correct)".

I have fixed the bug in the Gnulib version of the regex code, here:

http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=5513b40999149090987a0341c018d05d3eea1272

so when somebody backports Gnulib fixes into Glibc, Glibc should pick up the
bug fix as a part of that process.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]