Bug 323571 (CVE-2007-5116) - CVE-2007-5116 perl regular expression UTF parsing errors
Summary: CVE-2007-5116 perl regular expression UTF parsing errors
Alias: CVE-2007-5116
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 323781 323791 323801 323811 323821 349461 378121 378131 378141 378151 466966 466967 466968
TreeView+ depends on / blocked
Reported: 2007-10-08 19:03 UTC by Josh Bressers
Modified: 2023-05-11 12:28 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-12-19 09:07:54 UTC

Attachments (Terms of Use)
Patch for Perl 5.8 from Tavis (1.82 KB, patch)
2007-10-08 19:49 UTC, Josh Bressers
no flags Details | Diff
Corrected patch (1.82 KB, patch)
2007-11-12 18:42 UTC, Tomas Hoger
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:0966 0 normal SHIPPED_LIVE Important: perl security update 2008-01-08 18:00:52 UTC
Red Hat Product Errata RHSA-2007:1011 0 normal SHIPPED_LIVE Important: perl security update 2007-11-05 16:28:01 UTC
Red Hat Product Errata RHSA-2010:0602 0 normal SHIPPED_LIVE Moderate: Red Hat Certificate System 7.3 security update 2010-08-05 14:04:51 UTC

Description Josh Bressers 2007-10-08 19:03:52 UTC
Tavis Ormandy and Will Drewry have discovered a flaw in the way perl calculates
the space needed to process a regular expression.  It is possible to cause the
two passes to mismatch.  To quote their mail:

    The compile phase uses multiple passes (similar to older pcre releases),
    once to determine space requirements and another to actually compile the
    expression, however it's very simple to cause the two passes to mismatch.
    From the perl documentation:

    > The regular expression compiler produces polymorphic opcodes.That is,
    > the pattern adapts to the data and automatically switches to the Unicode
    > character scheme when presented with Unicode data--or instead uses a
    > traditional byte scheme when presented with byte data.

    This unfortunately means that you can cause the mode to switch at an
    arbitrary point, and then subsequent passes of any of the expression prior
    to this point switch will be passed differently, and thus potentially have
    their space requirements miscalculated.


Red Hat would like to thank Tavis Ormandy and Will Drewry for properly disclosing this issue.

Comment 2 Josh Bressers 2007-10-08 19:49:58 UTC
Created attachment 220101 [details]
Patch for Perl 5.8 from Tavis

Comment 3 Josh Bressers 2007-10-08 19:54:54 UTC
I don't believe this affects perl 5.6.  I wouldn't mind if someone could back me
up on this, but my research suggests that the 5.6 regular expression interpreter
is either in unicode mode or not, it can't switch, which means there can't be a
mismatch between the passes.

Comment 6 Tomas Hoger 2007-10-09 11:09:40 UTC
Part of perlunicode(1) from perl5.6 what corresponds to quote used in original

    The existing regular expression compiler does not produce polymorphic
    opcodes.  This means that the determination on whether to match Unicode
    characters is made when the pattern is compiled, based on whether
    the pattern contains Unicode characters, and not when the matching
    happens at run time.  This needs to be changed to adaptively match
    Unicode if the string to be matched is Unicode.

Comment 7 Josh Bressers 2007-10-09 18:19:04 UTC
This is going to be RHSA-2007:0966

Comment 14 Josh Bressers 2007-11-05 15:57:31 UTC
Lifting embargo

Comment 15 Tomas Hoger 2007-11-12 18:42:14 UTC
Created attachment 255541 [details]
Corrected patch

Original patch was mangled while being mailed, this one was used in updated
RHEL perl packages and really fixes the issue.

Comment 19 errata-xmlrpc 2010-08-04 21:32:43 UTC
This issue has been addressed in following products:

  Red Hat Certificate System 7.3

Via RHSA-2010:0602 https://rhn.redhat.com/errata/RHSA-2010-0602.html

Note You need to log in before you can comment on or make changes to this bug.