From: Tom Lane Date: Fri, 8 Jan 2021 17:16:00 +0000 (-0500) Subject: Fix ancient bug in parsing of BRE-mode regular expressions. X-Git-Tag: REL9_5_25~29 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0c23f30fad2919eb53964fa348ede60e504b5c1e;p=thirdparty%2Fpostgresql.git Fix ancient bug in parsing of BRE-mode regular expressions. brenext(), when parsing a '*' quantifier, forgot to return any "value" for the token; per the equivalent case in next(), it should return value 1 to indicate that greedy rather than non-greedy behavior is wanted. The result is that the compiled regexp could behave like 'x*?' rather than the intended 'x*', if we were unlucky enough to have a zero in v->nextvalue at this point. That seems to happen with some reliability if we have '.*' at the beginning of a BRE-mode regexp, although that depends on the initial contents of a stack-allocated struct, so it's not guaranteed to fail. Found by Alexander Lakhin using valgrind testing. This bug seems to be aboriginal in Spencer's code, so back-patch all the way. Discussion: https://postgr.es/m/16814-6c5e3edd2bdf0d50@postgresql.org --- diff --git a/src/backend/regex/regc_lex.c b/src/backend/regex/regc_lex.c index d68f88c7fc0..883b5cf1672 100644 --- a/src/backend/regex/regc_lex.c +++ b/src/backend/regex/regc_lex.c @@ -968,7 +968,7 @@ brenext(struct vars * v, case CHR('*'): if (LASTTYPE(EMPTY) || LASTTYPE('(') || LASTTYPE('^')) RETV(PLAIN, c); - RET('*'); + RETV('*', 1); break; case CHR('['): if (HAVE(6) && *(v->now + 0) == CHR('[') &&