Bug #77338 [Ver->Csd]: get_browser with empty string

From: Date: Wed, 26 Dec 2018 16:13:34 +0000
Subject: Bug #77338 [Ver->Csd]: get_browser with empty string
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-218624@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=77338&edit=1

 ID:                 77338
 Updated by:         nikic@php.net
 Reported by:        emondpph at gmail dot com
 Summary:            get_browser with empty string
-Status:             Verified
+Status:             Closed
 Type:               Bug
 Package:            Reproducible crash
 Operating System:   Mac OS Mojave
 PHP Version:        7.3.0
 Assigned To:        nikic
 Block user comment: N
 Private report:     N

 New Comment:

Automatic comment on behalf of nikita.ppv@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=b1deb98c42328488cfce61d49d9607ed44fff7a4
Log: Fixed bug #77338


Previous Comments:
------------------------------------------------------------------------
[2018-12-24 11:22:45] cmb@php.net

> Am I reading this right that the re_options parameter is basically
> bogus, because we set all the relevant options during compilation
> and the parts that are part of preg_options are not relevant for
> manual PCRE calls?

I'm not sure.  It might be relevant to get the information whether
the regexp has been compiled with or without JIT (i.e. whether
PREG_JIT is set).

Anyhow, the options that have been retrieved via the re_options
parameter of pcre_get_compiled_regex() must never be passed to the
options parameter of pcre2_match(), since these are different
bitsets.

------------------------------------------------------------------------
[2018-12-23 19:39:41] nikic@php.net

@cmb: Am I reading this right that the re_options parameter is basically bogus, because we set all
the relevant options during compilation and the parts that are part of preg_options are not relevant
for manual PCRE calls?

Ideally we'd just drop this parameter to avoid confusion, but as we can't do that for 7.3
we should just always set it to zero.

------------------------------------------------------------------------
[2018-12-23 19:23:21] nikic@php.net

I've fixed the invalid efree in 7.2+ via https://github.com/php/php-src/commit/64de5bc224584e1da08c5c2bdf76db72ccbaaaab.
The test case is a variation that makes this crash there as well, by not having any default.

We still need to fix the PCRE issue.

------------------------------------------------------------------------
[2018-12-23 18:49:54] cmb@php.net

The latter is due to a confusion regarding re_options[1]; these
are reported as 8, because PREG_JIT has been set[2], but the
following pcre2_match() interprets them as PCRE2_NOTEMPTY_ATSTART,
yielding no match.  This might be a general problem affecting
PCRE.

[1] <https://github.com/php/php-src/blob/php-7.3.0/ext/standard/browscap.c#L623>
[2] <https://github.com/php/php-src/blob/php-7.3.0/ext/pcre/php_pcre.c#L783>

------------------------------------------------------------------------
[2018-12-23 18:30:51] nikic@php.net

There's two things wrong here: An incorrect efree() that should be a zend_string_release()
(also exists in 7.2), and the fact that we hit this code path at all on 7.3, which indicates a
presumably not intended change in behavior.

------------------------------------------------------------------------


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=77338


--
Edit this bug report at https://bugs.php.net/bug.php?id=77338&edit=1


Thread (10 messages)

« previous php.bugs (#218624) next »