https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920
Bug ID: 98920 Summary: [10/11 Regression] uses regexec without support for REG_STARTEND with -fsanitize=address Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- [forwarded from https://bugs.debian.org/949192] When gcc-10 compiles with -fsanitize=address, it substitutes any calls to regexec with a version that does not support REG_STARTEND. This makes code that is compiled fail unexpectedly or even produce spurious sanitization errors, since with that option the buffer need not be NUL-terminated. While REG_STARTEND is not in POSIX, it is found on the BSDs and Linux and users may reasonably rely on the fact that it is present on those systems. This issue has caused a bug in the Git testsuite as seen at https://lore.kernel.org/git/20200117174931.ga8...@coredump.intra.peff.net/T/#t. I've attached a testcase. Without -fsanitize=address, it succeeds silently. With -fsanitize=address, it fails and prints an error. Please either fix the regexec implementation such that it is fully functional compared to the version in glibc or disable the sanitization of regexec until it has feature parity. $ cat test.c #include <stdio.h> #include <sys/types.h> #include <regex.h> int main(void) { regex_t r; const char s[] = "ban\0ana"; regmatch_t pmatch[10]; pmatch[0].rm_so = 0; pmatch[0].rm_eo = sizeof(s); if (regcomp(&r, "ana", 0)) return 2; if (regexec(&r, s, sizeof(pmatch)/sizeof(pmatch[0]), pmatch, REG_STARTEND)) { fprintf(stderr, "failed to match\n"); regfree(&r); return 3; } regfree(&r); return 0; } $ gcc-9 -fsanitize=address test.c && ./a.out $ gcc-10 -fsanitize=address test.c && ./a.out failed to match $ gcc-11 -fsanitize=address test.c && ./a.out failed to match