php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38600 libpcre needs update to 6.7: Infinite loop using preg_match
Submitted: 2006-08-25 21:14 UTC Modified: 2006-08-30 20:08 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: phillip dot berndt at googlemail dot com Assigned: andrei (profile)
Status: Closed Package: PCRE related
PHP Version: 5.1.5 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: phillip dot berndt at googlemail dot com
New email:
PHP Version: OS:

 

 [2006-08-25 21:14 UTC] phillip dot berndt at googlemail dot com
Description:
------------
When executing the code below, the function won't return but loop forever (or do something else, I don't know).

Reproduce code:
---------------
<?php
        $foo = 'bla bla bla';
        preg_match('/(?<!\w)(0x[\p{N}]+[lL]?|[\p{Nd}]+(e[\p{Nd}]*)?[lLdDfF]?)(?!\w)/', $foo);
?>

Expected result:
----------------
Something like that:

pberndt@locutus ~ $ time perl -e '$_="bla bla bla"; /(?<!\w)(0x[\p{N}]+[lL]?|[\p{Nd}]+(e[\p{Nd}]*)?[lLdDfF]?)(?!\w)/;'

real    0m0.017s
user    0m0.016s
sys     0m0.000s


Actual result:
--------------
pberndt@locutus ~ $ php
<?php
        set_time_limit(10);
        $foo = 'bla bla bla';
        preg_match('/(?<!\w)(0x[\p{N}]+[lL]?|[\p{Nd}]+(e[\p{Nd}]*)?[lLdDfF]?)(?!\w)/', $foo);
?>


Fatal error: Maximum execution time of 10 seconds exceeded in /home/pberndt/- on line 4


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-08-25 21:39 UTC] tony2001@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip


 [2006-08-26 13:40 UTC] phillip dot berndt at googlemail dot com
Same result for a fresh php5.2-200608261230 build.

I don't know, whether this helps, but in this build I interrupted the process after about 10 seconds; here's the bt:

#0  adjust_recurse (group=0x84706db "R", adjust=1, utf8=0, cd=0xbfd088e0) at /home/pberndt/php_snap/php5.2-200608261230/ext/pcre/pcrelib/pcre_compile.c:1117
#1  0x08080269 in compile_regex (options=0, oldims=0, brackets=0xbfd084a4, codeptr=0xbfd08344, ptrptr=0xbfd0837c, errorcodeptr=0xbfd084dc, lookbehind=0,
    skipbytes=0, firstbyteptr=0x0, reqbyteptr=0x0, bcptr=0x3d, cd=0xbfd088e0) at /home/pberndt/php_snap/php5.2-200608261230/ext/pcre/pcrelib/pcre_compile.c:2681
#2  0x0807e71a in compile_regex (options=0, oldims=0, brackets=0xbfd084a4, codeptr=0xbfd084a8, ptrptr=0xbfd084d8, errorcodeptr=0xbfd084dc, lookbehind=0,
    skipbytes=0, firstbyteptr=0x0, reqbyteptr=0x0, bcptr=0x3d, cd=0xbfd088e0) at /home/pberndt/php_snap/php5.2-200608261230/ext/pcre/pcrelib/pcre_compile.c:3177
#3  0x08081339 in php_pcre_compile2 (pattern=0xb7bdf6d8 "(?<!\\w)(0x[\\p{N}]+[lL]?|[\\p{Nd}]+(e[\\p{Nd}]*)?[lLdDfF]?)(?!\\w)", options=0, errorcodeptr=0x0,
    errorptr=0xbfd089a4, erroroffset=0xbfd089a8, tables=0x8470220 "") at /home/pberndt/php_snap/php5.2-200608261230/ext/pcre/pcrelib/pcre_compile.c:4983
#4  0x080829a3 in php_pcre_compile (pattern=0x0, options=0, errorptr=0x0, erroroffset=0x0, tables=0x0)
    at /home/pberndt/php_snap/php5.2-200608261230/ext/pcre/pcrelib/pcre_compile.c:3905
#5  0x0808bfad in pcre_get_compiled_regex_cache (regex=0xb7be4bd4 "/(?<!\\w)(0x[\\p{N}]+[lL]?|[\\p{Nd}]+(e[\\p{Nd}]*)?[lLdDfF]?)(?!\\w)/", regex_len=64)
    at /home/pberndt/php_snap/php5.2-200608261230/ext/pcre/php_pcre.c:324
#6  0x0808d225 in php_do_pcre_match (ht=2, return_value=0xb7be4c20, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, global=0)
    at /home/pberndt/php_snap/php5.2-200608261230/ext/pcre/php_pcre.c:457
#7  0x082292d7 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfd08b60) at zend_vm_execute.h:200
#8  0x08228bdc in execute (op_array=0xb7be47d8) at zend_vm_execute.h:92
#9  0x0820dabe in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/pberndt/php_snap/php5.2-200608261230/Zend/zend.c:1095
#10 0x081cfb86 in php_execute_script (primary_file=0xbfd0b060) at /home/pberndt/php_snap/php5.2-200608261230/main/main.c:1759
#11 0x082963b0 in main (argc=1, argv=0xbfd0b144) at /home/pberndt/php_snap/php5.2-200608261230/sapi/cli/php_cli.c:1102
 [2006-08-26 14:55 UTC] phillip dot berndt at googlemail dot com
This should be the problem:

ChangeLog for PCRE
------------------
Version 6.7 04-Jul-06
[...]
 4. When UTF-8 mode was not set, PCRE looped when compiling certain patterns
    containing an extended class (one that cannot be represented by a bitmap
    because it contains high-valued characters or Unicode property items, e.g.
    [\pZ]). Almost always one would set UTF-8 mode when processing such a
    pattern, but PCRE should not loop if you do not (it no longer does).
    [Detail: two cases were found: (a) a repeated subpattern containing an
    extended class; (b) a recursive reference to a subpattern that followed a
    previous extended class. It wasn't skipping over the extended class
    correctly when UTF-8 mode was not set.]
[...]
 [2006-08-26 22:33 UTC] phillip dot berndt at googlemail dot com
Changed title to fit better. Sorry for posting another comment, I can't submit the update without posting something :)

I just tested updating the php source to use the newest libpcre - everything is working perfectly.
 [2006-08-30 20:08 UTC] iliaa@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Mon May 12 04:01:29 2025 UTC