php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31048 PHP crashes if fpassthru() is used along with fseek()
Submitted: 2004-12-10 02:39 UTC Modified: 2004-12-24 01:00 UTC
Votes:3
Avg. Score:4.3 ± 0.9
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: john dot wellesz at teaser dot fr Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 5.0.2 OS: FreeBSD 4.9 STABLE and WINXPSP2
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: john dot wellesz at teaser dot fr
New email:
PHP Version: OS:

 

 [2004-12-10 02:39 UTC] john dot wellesz at teaser dot fr
Description:
------------
The bug I'm about to describe happens on Windows XP SP2 and freeBSD 4.9 STABLE and probably other platforms (I'm currently using PHP 5.0.2 on both).

My 2 php (winXP and FreeBSD) run as CGI, the crashes also happens if I execute my script on command line.

Modules used is probably irrelevant (and futile?), I use 2 PHP, one on FreeBSD and the other on winXP compiled on totally different way with not the same modules... (tell me if you can't reproduce the crash, i'll provide more info).

----------------
BUG REQUIREMENTS:

--> You must have a file of at least 300Kb in size (200Kb won't make PHP to crash)
--> You must have set the file pointer with fseek at 200,000 bytes (other values may not produce the bug) from the beginning of the file.
--> You must call fpassthru() to print the rest of the file.

Reproduce code:
---------------
<?php
//test file path
$loginfo="fpassthru_crash_test_file";

//create the file;
touch($loginfo);

//allocate ~300000 bytes in the files (the file will make 300003 bytes)
$handle=fopen($loginfo, "r+b");
ftruncate($handle,0);
fseek($handle, 300000, SEEK_END);
fwrite($handle,"END");
fclose($handle);

//Open it for reading
$handle=fopen($loginfo, "rb");
fseek($handle, 200000, SEEK_SET);//the 200000 is important, other values may not trigger the bug

fpassthru($handle);
?>

Expected result:
----------------
PHP should print the file till the end, we should see "END"...

Actual result:
--------------
PHP displays the file till the 98304th byte and crashes with a bus error (Signal 10).

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-12-10 09:13 UTC] derick@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
 [2004-12-10 18:36 UTC] john dot wellesz at teaser dot fr
Do you mean that the code provided doesn't make your PHP 5.0.2 to crash? If yes, then try to increase the size of the test file ("fpassthru_crash_test_file") to 2Mb. You can also try to increase the position of the file pointer.

The problem looks like a buffer overflow...

I'm not a PHP developper, I don't have the tools needed to make the backtrace, I don't have admin access to the machine running under FreeBSD 4.9... And doing it under winXPSP2 will take hours of my time (if ever it is possible), whereas it would take at most 15 minutes for a PHP developper who already have have all the tools needed.

Thank you.
 [2004-12-13 20:21 UTC] john dot wellesz at teaser dot fr
Your Bug Report script split lines so the code I provided will only make syntax errors (commented lines are split).

So here is the uncommented code:

<?php
$loginfo="fpassthru_crash_test_file";

touch($loginfo);

$handle=fopen($loginfo, "r+b");
ftruncate($handle,0);
fseek($handle, 300000, SEEK_END);
fwrite($handle,"END");
fclose($handle);


$handle=fopen($loginfo, "rb");
fseek($handle, 200000, SEEK_SET);

fpassthru($handle);
?>

I hope you'll be able to reproduce it :-)
 [2004-12-14 02:18 UTC] wez@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Read the link; it tells you how to make a backtrace; without one we can't fix the bug.
 [2004-12-16 00:02 UTC] john dot wellesz at teaser dot fr
OK, The bug doesn't happen in php 5.0.3 (at least on windows XP sp2).

I've been able to generate a core dump but without the --enable-debug parameter, plus I've made a kdump.

First the kdump (I've called ob_start() just before the call to  fpassthru() since it didn't change anything and make the trace shorter):

ktrace is launched just before the line:

"$handle = fopen($loginfo, "rb");"

------------Kdump Result:

67985 php      RET   read 0
 67985 php      CALL  close(0x3)
 67985 php      RET   close 0
 67985 php      CALL  wait4(0x10994,0xbfbfd9dc,0,0)
 67985 php      RET   wait4 67988/0x10994
 67985 php      CALL  nanosleep(0xbfbfdab8,0xbfbfdab0)
 67985 php      RET   nanosleep 0
 67985 php      CALL  __getcwd(0xbfbfd5d0,0x400)
 67985 php      RET   __getcwd 0
 67985 php      CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php      NAMI  "/home"
 67985 php      RET   lstat 0
 67985 php      CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php      NAMI  "/home/_j2"
 67985 php      RET   lstat 0
 67985 php      CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php      NAMI  "/home/_j2/j2072"
 67985 php      RET   lstat 0
 67985 php      CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php      NAMI  "/home/_j2/j2072/pub"
 67985 php      RET   lstat 0
 67985 php      CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php      NAMI  "/home/_j2/j2072/pub/www.2072productions.com"
 67985 php      RET   lstat 0
 67985 php      CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php      NAMI  "/home/
_j2/j2072/pub/www.2072productions.com/fpassthru_crash_test_file"
 67985 php      RET   lstat 0
 67985 php      CALL  open(0x8205e8c,0,0x1b6)
 67985 php      NAMI  "/home/
_j2/j2072/pub/www.2072productions.com/fpassthru_crash_test_file"
 67985 php      RET   open 3
 67985 php      CALL  fstat(0x3,0x817892c)
 67985 php      RET   fstat 0
 67985 php      CALL  lseek(0x3,0,0,0,0x1)
 67985 php      RET   lseek 0
 67985 php      CALL  lseek(0x3,0,0x30d40,0,0)
 67985 php      RET   lseek 200000/0x30d40
 67985 php      CALL  break(0x8222000)
 67985 php      RET   break 0
 67985 php      CALL  fstat(0x3,0x817892c)
 67985 php      RET   fstat 0
 67985 php      CALL  mmap(0,0x493e3,0x1,0x1,0x3,0,0x30d40,0)
 67985 php      RET   mmap 677834048/0x2866ed40
 67985 php      CALL  break(0x826e000)
 67985 php      RET   break 0
 67985 php      PSIG  SIGBUS SIG_DFL
 67985 php      NAMI  "/var/cores/php"


------------Now the result of GDB:

#0  0x284212a6 in memcpy () from /usr/lib/libc.so.4
(gdb) #0  0x284212a6 in memcpy () from /usr/lib/libc.so.4
Cannot access memory at address 0xbfbfba2c.
(gdb) 


I can't do better, I hope this will be sufficient :-)
 [2004-12-16 09:51 UTC] derick@php.net
You can actually, type "bt" on the GDB prompt after it crashed. That will make a backtrace which is very useful for us.

Thanks
 [2004-12-24 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2005-04-01 14:04 UTC] thomas at mbox371 dot swipnet dot se
I am having this problem as well with 5.0.4 and latest apache2 on windows 2003. I also have the problem that even without fseek the file submission stops after a minute or so (streaming mp3).
I wanted 5.0.4 for the bugfix of the XML parser but there always seems to be one or more new bugs that stops me from upgrading :( file passthru has been broken several times now :( I have debuged my passthru/readfile code several hours in total now and i'm not doing it again. I cant even make myself to diagnose the problem, just hoping that someone else does it.. I will revert to 5.0.3 instead. PHP is too confusing :(
 [2005-04-08 17:58 UTC] thomas at mbox371 dot swipnet dot se
It works now. It might have been fix of bug 32553 that did it for me.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat May 18 12:01:32 2024 UTC