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.ha...@gmail.com
Reporter: alt.nl-eoq83...@yopmail.com
CC: pcre-dev@exim.org
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.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
