Closed longuu9 closed 1 year ago
Please don't spam the project. It takes a lot of effort to investigate even one report, especially if the poc is vague. If nothing more, create a minimal test case.
Btw issues in the pcre2test program and invalid utf when valid utf is expected are ignored. Most of the reports we receive are belong to these categories.
Thanks. This is another issue in pcre2test. The expanding writes too much data.
#pattern convert=
/\[()]{65535}/expand
It can be fixed, but we do not fix bugs in the test system in general, since it takes time and provides zero advantage, since the test system is not used for production.
Thanks; I was already looking at 236 yesterday and had come to the same conclusion (then I ran out of time). I may fix it if it is easy, but I entirely agree that bugs in pcre2test are of low priority.
I have fixed this issue by giving an error and abandoning the test if a pattern conversion results in a string that is too long.
We found a heap-buffer-overflow in pcre2-10.43-DEV(src/pcre2test.c:5831:5 in process_pattern ),which can also be reproduced on pcre2-10.42.
Command Input
pcre2test -d poc_file /dev/null
poc_file are attached.
Sanitizer Dump
Environment
we built pcre2 with AddressSanitizer (ASAN) .
poc_file.zip