in reply to THREE new perl releases

CVE-2023-47038 is only relevant during the use of \p in regexes. This is only a problem if you accept regular expressions from untrusted sources.

Interesting. I guess they can't blame me for this, as I haven't released my Thai module yet! (However, I have no idea why or how such an error could occur simply with the use of \p{...} characters in one's regex--how can a unicode property definition be illegal?)

For what it's worth, I discovered that my nomenclature for the \p{...} characters was illegal--but they never produced an error message like that...they just didn't work, as if they had not been defined or imported. I learned that there are only two possibilities with names of unicode properties:

\p{InProperty} \p{IsProperty}

Using something like '\p{Property}' is illegal--it must be prefixed by either "In" or by "Is" or Perl will not accept it or recognize it.

But the error shown here in the OP doesn't appear to have much to do with this, leaving me to wonder what it is for.

Blessings,

~Polyglot~

Replies are listed 'Best First'.
Re^2: THREE new perl releases
by sectokia (Friar) on Dec 03, 2023 at 22:27 UTC
    Its because perl regexp itself is coded in C. In this case the code for /p was stripping 'utf8::' from the string, but not adjusting the position/length of the buffer properly to account for that stripping along all code paths, allowing you to craft a buffer overflow exploit.