Home Original page

PHP :: Bug #75207 :: preg_match bug

Bug #75207 preg_match bug
Submitted: 2017-09-14 08:46 UTC Modified: 2017-09-28 13:48 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: qflbapp at gmail dot com Assigned: ab (profile)
Status: Closed Package: PCRE related
PHP Version: 7.1.9 OS: Linux Ubuntu
Private report: No CVE-ID: None

 [2017-09-14 08:46 UTC] qflbapp at gmail dot com

Description:
------------
php test.php

*** Error in `php': double free or corruption (!prev): 0x0000000002b0dec0 ***
Aborted

Test script:
---------------
<?php
preg_match("/š(?:F?+(?:^(?(R)a+\"){99}-))(?J)(?'R'(?'R'<((?'RR'(?'R'\){97)?J)?J)(?'R'(?'R'\){99|(:(?|(?'R')(\k'R')|((?'R')))H'R'R)(H'R))))))/","$a*b\dc");
?>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

 [2017-09-14 21:07 UTC] stas@php.net

-Type: Security +Type: Bug

 [2017-09-14 21:08 UTC] stas@php.net

-Package: *General Issues +Package: PCRE related

 [2017-09-14 21:09 UTC] stas@php.net

This looks like PCRE issue, did you report it to the PCRE maintainers?

 [2017-09-15 02:02 UTC] qflbapp at gmail dot com

I did't report to the PCRE maintainers.

 [2017-09-18 14:30 UTC] Philip dot Hazel at gmail dot com

It has now been reported to the PCRE maintainers, but with no information about the PCRE version. I cannot reproduce a problem with the given pattern - it gives an immediate "unmatched parentheses" error, with or without the backslashes (does PHP remove them?).

 [2017-09-18 16:22 UTC] cmb@php.net

-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb

 [2017-09-18 16:22 UTC] cmb@php.net

> I cannot reproduce a problem with the given pattern […]

Neither can I with PCRE 8.41 (PCRE 8.38 exhibits the bad behavior, though).

@qflbapp Please provide the PCRE_VERSION you are using.

> […] with or without the backslashes (does PHP remove them?).

PHP requires to enclose the regular expression with an arbitrary character (in
this case a slash has been chosen), to separate the actual regexp from the
modifier characters (if any).

 [2017-09-18 16:45 UTC] Philip dot Hazel at gmail dot com

Thanks for checking it out. I too can reproduce with 8.38, but not with 8.39 or 8.41 (latest - I didn't bother with 8.40) or with PCRE2 (10.30). Clearly this bug has been fixed. The 8.39 ChangeLog, on a quick scan, does show a bugfix (#14) which is probably the one. 8.38 is nearly 2 years old now. I am going to close the PCRE bug report as already fixed.

 [2017-09-18 17:12 UTC] cmb@php.net

-Assigned To: cmb +Assigned To: ab

 [2017-09-18 17:12 UTC] cmb@php.net

Thanks, Philip, that was very helpful.

Anatol, the bug Philip mentions has been assigned CVE-2016-1283[1], but PHP-7.0
and PHP-7.1 still ship 8.38. Should these be updated, even though that does not
qualify as security issue for PHP, since arbitrary regexps should never be
accepted from untrusted input, IMO.

[1] <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1283>

 [2017-09-18 17:12 UTC] cmb@php.net

-Status: Feedback +Status: Analyzed

 [2017-09-18 18:16 UTC] spam2 at rhsoft dot net

just update PCRE!

not so long ago i had to recompile mod_security without prce-jit-support because we had segfaults due a dist-upgrade which leade to segfaults because the *path* of a roundcuebmail javascript

https://bugzilla.redhat.com/show_bug.cgi?id=1215701

in the meantime no problem any longer

 [2017-09-19 16:35 UTC] ab@php.net

Thanks for the ping, Christoph. I'd be not a big fan of upgrading PCRE, especially in 7.0. The diff is huge not only for PCRE itself, but for ext/pcre, too. With 7.1, too. Not only that, but also it'll require to backport the valgrind support for ext/pcre and run-tests.php, etc. The weight of this issue certainly doesn't justify the backport effort and possible impacts. IMHO, applying the upstream patch is more appropriate. I'll be checking for possible directions.

Regards

Anatol

 [2017-09-28 13:48 UTC] ab@php.net

-Status: Analyzed +Status: Closed

 [2017-09-28 13:48 UTC] ab@php.net

Upstream patch applied with d11fceab151cd0410645f81eb7444af4388470c3.

Thanks.