Ok, thanks for clarification. So, do you have any idea how the regexp should look like in order to reproduce the issue from bug?
Thank you very much! On Tue, 5 May 2020, 13:24 Aurelien Jarno, <[email protected]> wrote: > Hi, > > On 2020-05-05 12:14, Raluca-Petronela Florea wrote: > > Hello, > > > > I'm working on fixing some GLIBC vulnerabilities and I have an issue > > regarding > > CVE-2015-8985 - Assertion failure in pop_fail_stack when executing a > > malformed regexp > > > > Although it seems to be fixed in glibc 2.28, I've encountered the > following > > issue testing on a Ubuntu 19.10 virtual machine with glibc > 2.30-0ubuntu.2.1 > > the following program: > > > > pop_fail_stack.c > > > > #include <assert.h> > > #include <regex.h> > > #include <stdio.h> > > > > int main(int argc, char **argv) > > { > > int rc; > > regex_t preg; > > regmatch_t pmatch[2]; > > > > rc = regcomp(&preg, "()*)|\\1)*", REG_EXTENDED); > > assert(rc == 0); > > regexec(&preg, "", 2, pmatch, 0); > > regfree(&preg); > > return 0; > > } > > > > *pop_fail_stack: pop_fail_stack.c:12: main: Assertion `rc == 0' failed.* > > *Aborted (core dumped)* > > It means you glibc has the fix. The regex is clearly invalid so it > regcomp correctly fails to compile it. > > > As describes the Debian bug > > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779392), the test > > program compiles an invalid regexp and then tries to match a string > > against it, triggers an assertion: > > > > *pop_fail_stack: regexec.c:1401: pop_fail_stack: Assertion `num >= 0' > failed. > > Aborted* > > That error message means the glibc is not fixed, i.e. regcomp is wronglu > able to compile it and regexec later triggers an assertion inside glibc > code. > > > So, in my scenario, the test program does not even successfully > > compile the invalid regexp. > > This is normal as the regexp is invalid, so it can't be compiled. > > Regards, > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > [email protected] http://www.aurel32.net >
