[pcre-dev] [Bug 2654] New: stack overwrite using pcreposix A…

Top Page
Delete this message
Author: admin
Date:  
To: pcre-dev
Subject: [pcre-dev] [Bug 2654] New: stack overwrite using pcreposix API with musl libc
https://bugs.exim.org/show_bug.cgi?id=2654

            Bug ID: 2654
           Summary: stack overwrite using pcreposix API with musl libc
           Product: PCRE
           Version: 8.44
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Code
          Assignee: Philip.Hazel@???
          Reporter: alt.nl-eoq83dkw@???
                CC: pcre-dev@???


i've been trying to use pcre's posix api as a drop-in replacement for faster
regex execution, but was greeted by stack overwrites and segfault in the
caller.
after some analysis i figured out what went wrong:

1) pcre defines regoff_t as int, musl libc as "ssize_t" (i.e. long)
2) musl's regexec function was used, but pcre's header, and having regoff_t
being 2x as big overwrote the stack.

2 happens because, afaict, there's no way to make linking prefer
libpcreposix.(a|so) over libc.(a|so) because that's the hardcoded linking order
in gcc. so if libc offers regexec/regcomp etc, it will always use these
symbols.

in order to make pcre's posix functions usable in such an environment, the
library
itself needs to use different symbol names than the libc, e.g.
pcre_posix_regcomp and use some macro magic in the header to redirect the
caller to use those, e.g.
#define regcomp pcre_posix_regcomp

that way it doesn't matter whether -lc or -lpcreposix comes first in the linker
command line, and size difference between types is of no concern.

additionally pcre *should* use a size_t-sized regoff_t such as ssize_t, but i
can see that this could cause ABI problems with existing users; however if new
symbols like pcre_posix_regcomp are introduced which are automatically used via
macro magic this could be made possible as long as ABI-compatible function
stubs for the old symbol names would continue using 32bit sized regoff_t.

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