php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45573 unserialize does not work if a linebreak is inside the input string
Submitted: 2008-07-20 20:23 UTC Modified: 2016-07-26 23:03 UTC
From: t_mueller_stolzenhain at yahoo dot de Assigned:
Status: Not a bug Package: Strings related
PHP Version: any OS: any
Private report: No CVE-ID: None
 [2008-07-20 20:23 UTC] t_mueller_stolzenhain at yahoo dot de
Description:
------------
After updating PHP to version 5.2.6 on a windows 2003 server running under IIS, it was not possible to update PEAR anymore. Each package created some error messages like

Notice: unserialize(): Error at offset 1139 of 4783 bytes in PEAR\Registry.php on line 1062


After putting the line

$data = str_replace("\15\12", "\12", $data);

before the unserialize-including line, the error message disappeared an I was able to update PEAR again.

I asume, this is an IIS related issue, because on an other Computer with PHP 5.2.5 (running on Win XP and Apache) are no error messages.

Reproduce code:
---------------
These are the lines 1058-1064 from /PEAR/PEAR/Registry.php including one line with an fix

        $this->_closePackageFile($fp);
        $data = file_get_contents($this->_packageFileName($package, $channel));
        set_magic_quotes_runtime($rt);
        $data = str_replace("\15\12", "\12", $data);//additional line with fix
        $data = unserialize($data);
        if ($key === null) {
            return $data;
        }

Expected result:
----------------
no error message

Actual result:
--------------
e.g.

Notice: unserialize(): Error at offset 1139 of 4783 bytes in PEAR\Registry.php on line 1062


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-23 21:40 UTC] t_mueller_stolzenhain at yahoo dot de
I tried the package from http://snaps.php.net/win32/php5.2-win32-latest.zip, but the error is still there.

I changed the category for this bug, because the PEAR update was not running inside the browser, it was running inside a dos window.
 [2008-07-24 00:31 UTC] jani@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.


 [2008-07-24 21:10 UTC] t_mueller_stolzenhain at yahoo dot de
I don't have a sample script (I'm not able to create an text with two different line endings in it), but I found the reason for that issue:

As you know, PEAR is storing some information inside the .registry directory in *.reg files. Some of these files I found converted to the windows style, means they had a windows line ending ("\15\12") instead of the linux line ending ("\12").

After reformating these files with the linux line ending, the error messages disappeared, and the PEAR update was running without any error messages.

I asume, the most of the files on a windows computer have the windows line ending included, not the linux line ending.

PHP is able to detect that it is running on a windows computer, and unserialize should be able to handle the windows line ending without error message.
 [2008-07-24 23:04 UTC] jani@php.net
As long as there is no preproducing script, there is no problem either.
 [2008-07-25 19:18 UTC] t_mueller_stolzenhain at yahoo dot de
sample to reproduce the error I had:
<?php
//the original array
$a = array(
    'a23' => 'abcdefg
hij'
);
//make it serial
$s = serialize($a);
//just to see the serial string
var_dump($s);
//the serialized array
$s1 = 'a:1:{s:3:"a23";s:11:"abcdefg
hij";}';
//the same with linux line end character
$s2 = "a:1:{s:3:\"a23\";s:11:\"abcdefg\12hij\";}";
//the same with windows line end character, same I had in my PEAR files
$s3 = "a:1:{s:3:\"a23\";s:11:\"abcdefg\15\12hij\";}";
//turn it back to an array
$a1 = unserialize($s1); // ok
$a2 = unserialize($s2); // ok
$a3 = unserialize($s3); // not ok
?>
 [2015-06-30 14:49 UTC] josh at josheaton dot org
I'm wondering why this issue never got any attention even with a reduced test case that reproduced the issue? I recently ran into this issue with a WordPress site and found this bug.

WordPress ticket: https://core.trac.wordpress.org/ticket/23275#comment:7

netweb was kind enough to provide a link that tests the issue in many different PHP versions, and it appears to break in all of them. Any windows line endings within a serialized string break when unserialized.

http://3v4l.org/X0pFQ

Is it possible to reopen this issue?
 [2015-07-01 05:39 UTC] yohgaki@php.net
-Status: Not a bug +Status: Re-Opened -Package: CGI/CLI related +Package: Strings related -Operating System: windows2003 +Operating System: any -PHP Version: 5.2CVS-2008-07-23 +PHP Version: any
 [2015-07-01 05:39 UTC] yohgaki@php.net
@josh
Because this is marked as Not a Bug. I re-opened this.
 [2015-07-01 11:55 UTC] cmb@php.net
-Assigned To: fb-req-jani +Assigned To:
 [2015-07-01 11:55 UTC] cmb@php.net
This is not a general bug. unserialize() fails due to the wrong
string length; s:11 has to be changed to s:12 when the LF is
replaced by CRLF, see <http://3v4l.org/u03Ek>.

The PEAR issue still may be an issue or not.
 [2016-07-26 23:03 UTC] nikic@php.net
-Status: Re-Opened +Status: Not a bug
 [2016-07-26 23:03 UTC] nikic@php.net
Closing here, as this is working as intended. The serialized string has been corrupted and consequently unserialize fails.

Serialized data is binary data, it can't be treated as "text".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 07 05:01:29 2024 UTC