|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75207 preg_match bug
Submitted: 2017-09-14 08:46 UTC Modified: 2017-09-28 13:48 UTC
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
php test.php

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

Test script:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-09-14 21:07 UTC]
-Type: Security +Type: Bug
 [2017-09-14 21:08 UTC]
-Package: *General Issues +Package: PCRE related
 [2017-09-14 21:09 UTC]
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]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2017-09-18 16:22 UTC]
> 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]
-Assigned To: cmb +Assigned To: ab
 [2017-09-18 17:12 UTC]
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] <>
 [2017-09-18 17:12 UTC]
-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

in the meantime no problem any longer
 [2017-09-19 16:35 UTC]
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.


 [2017-09-28 13:48 UTC]
-Status: Analyzed +Status: Closed
 [2017-09-28 13:48 UTC]
Upstream patch applied with d11fceab151cd0410645f81eb7444af4388470c3.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Jun 14 07:01:49 2024 UTC