Bug #75207 [Ana->Csd]: preg_match bug

From: Date: Thu, 28 Sep 2017 13:48:37 +0000
Subject: Bug #75207 [Ana->Csd]: preg_match bug
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-211418@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=75207&edit=1 ID: 75207 Updated by: ab@php.net Reported by: qflbapp at gmail dot com Summary: preg_match bug -Status: Analyzed +Status: Closed Type: Bug Package: PCRE related Operating System: Linux Ubuntu PHP Version: 7.1.9 Assigned To: ab Block user comment: N Private report: N New Comment: Upstream patch applied with d11fceab151cd0410645f81eb7444af4388470c3. Thanks. Previous Comments: ------------------------------------------------------------------------ [2017-09-19 16:35:05] 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-18 18:16:11] 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-18 17:12:12] 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 16:45:46] 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 16:22:04] 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). ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=75207 -- Edit this bug report at https://bugs.php.net/bug.php?id=75207&edit=1

« previous php.bugs (#211418) next »