php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67375 JIT enabled sometimes breaks filters
Submitted: 2014-06-03 17:21 UTC Modified: 2014-07-03 06:32 UTC
Votes:1
Avg. Score:2.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: garyamort at gmail dot com Assigned:
Status: Open Package: Filter related
PHP Version: 5.5.13 OS: Arch Linux 64bit
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: garyamort at gmail dot com
New email:
PHP Version: OS:

 

 [2014-06-03 17:21 UTC] garyamort at gmail dot com
Description:
------------
In some situations, if you have auto_globals_jit enables then not only are super global variables not initialized unless they are called, the underlying data storage for the original data[used by filter_input] will not be populated.

As I read filter.c, there seems to be a weird schism on how it deals with this.
https://github.com/php/php-src/blob/master/ext/filter/filter.c#L526

For INPUT_SERVER and INPUT_ENV it seems as if filter will make sure to initialize the data, example:
        if (PG(auto_globals_jit)) {
                                zend_is_auto_global("_SERVER", sizeof("_SERVER")-1 TSRMLS_CC);
                        }

For INPUT_POST, INPUT_GET, and INPUT_COOKIE however there is no safety net.

Test script:
---------------
<?php

// execute from web browser as http://domain/filename.php?test=123

$before = filter_input(INPUT_GET, 'test');  // $before = null
$var = $_GET('test');           // $var = 'test'
$after = filter_input(INPUT_GET, 'test');       // $after = 'test'

if ($before !== $after)
{
echo 'Raw input failed to load';
}


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-06-03 17:26 UTC] garyamort at gmail dot com
Note: I am not able to recreate this error at this time.   I am running under Arch Linux which as an extremely odd PHP package - virtually every module is installed as a shared library rather - even rather basic libraries such as sockets.

Since discovering this error, I created my own package and recompiled moving most shared php module libraries to static and the problem went away.  This leads me to think that either the problem is that there is no 'safety net' definitions for PARSE_GET, PARSE_POST, and PARSE_COOKIE here https://github.com/php/php-src/blob/master/ext/filter/filter.c#L68

OR that I simply messed up something when I was testing
 [2014-06-04 01:35 UTC] tyrael@php.net
https://bugs.php.net/bug.php?id=67296 is a possible duplicate for this one.
 [2014-07-03 06:32 UTC] tyrael@php.net
nope, https://bugs.php.net/bug.php?id=67296 is unrelated.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 10:01:30 2024 UTC