Created mingw-pcre tracking bugs for this issue:

Affects: fedora-all [bug 1848442]


Created pcre tracking bugs for this issue:

Affects: fedora-all [bug 1848441]

Upstream bug report <https://bugs.exim.org/show_bug.cgi?id=2463>
Upstream fix <https://vcs.pcre.org/pcre?view=revision&revision=1761>

There's an integer overflow possible in the compile_branch() routine in pcre.compile.c when parsing the callout argument. The patch ensures that the callout numerical argument is between 0-255.

I don't think this bug has any security implications. If pcre library encounters a callout with a user-supplied number in a regular expression (e.g. "(?C1)"), it will parse the number ("1" in this example) as a sequence of decimal digits and stores it into an integer temporary variable. If the user supplied a number larger then INT_MAX, the value of the variable overflows. Then if the overflowed value less then 255 (e.g. -1), pcre library won't signal a syntax error when compiling the expressions. But this is clear user's mistake as pcre_callout(3) reads:

       [...] Different callout  points
       can  be  identified  by putting a number less than 256 after the letter C.

Nevertheless, the library will continue and the integer value will be stored into an unsigned integer wide 8, 16, or 32 bits depending on the linked PCRE library (for UTF-8, UTF-16, UTF-32 support) of a compiled regular expression. That can misinterpret the negative and too big values further.

Then when the compiled expression is matched against a subject string, and if the user registered a callout callback function, the PCRE library will copy the value from the compiled expression into an integer member of pcre_callout_block structure and will pass that structure to the user's callback function. It's up-to the application what it will do with the number. The library does not process the number in any other way.

So the only outcome of this flaw is that an application that did not held the contract (passed a number larger then 255) will obtain the garbled value back in a callback. E.g. in case of the default 8-bit PCRE library, the too large number is returned back as a value in the the range from 0 to 255:

$ printf '%s\n%s\n' '/(?C254)/' 'a' |  pcretest 
PCRE version 8.42 2018-03-20

  re> data> --->a
254 ^     
 0: 
data> 

$ printf '%s\n%s\n' '/(?C4294967297)/' 'a' |  pcretest 
PCRE version 8.42 2018-03-20

  re> data> --->a
  1 ^     
 0: 
data> 

If I read the code properly, the garbled value should not influence (e.g. overwrite) any other data or code of the library.

In reply to comment #7:
> So the only outcome of this flaw is that an application that did not held
> the contract (passed a number larger then 255) will obtain the garbled value
> back in a callback.
> If I read the code properly, the garbled value should not influence (e.g.
> overwrite) any other data or code of the library.

Petr,

Did some further testing using pcretest and I agree with you; it looks like a sort of gray area case where the library itself doesn't have the bug since it only handles numbers in the specified range, but misuse of the library could cause a security issue. It looks like upstream applied a patch anyway, to avoid any misuse issues. I've changed the Impact to Low, but even as a Moderate, it's up to you if you want to apply the patch or WONTFIX.

Mitigation:

This flaw can be mitigated by not compiling regular expressions with a callout value greater outside of 0-255 or handling the value passed to the callback within the application code.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:4373 https://access.redhat.com/errata/RHSA-2021:4373

This issue has been addressed in the following products:

  Red Hat JBoss Core Services

Via RHSA-2021:4613 https://access.redhat.com/errata/RHSA-2021:4613

This issue has been addressed in the following products:

  JBoss Core Services on RHEL 7
  JBoss Core Services for RHEL 8

Via RHSA-2021:4614 https://access.redhat.com/errata/RHSA-2021:4614