tried to allocate 4294967296 bytes in dicom.php on line 3441

Known bugs reported by PacsOne users
Post Reply
tburba
Posts:50
Joined:Fri Apr 23, 2010 5:02 pm
Contact:
tried to allocate 4294967296 bytes in dicom.php on line 3441

Post by tburba » Tue Jan 17, 2012 5:02 pm

PacsOne 6.3.1, PHP 5.3.3-7+squeeze3, Linux 2.6.39-bpo.2-amd64. The error appears when executing showTags.php on some files.

A quick fix:

Code: Select all

diff -EbBu dicom.php.ORIG dicom.php
--- dicom.php.ORIG      2012-01-17 17:24:50.000000000 +0200
+++ dicom.php   2012-01-17 17:26:37.000000000 +0200
@@ -3434,6 +3434,8 @@
             $data = fread($this->handle, $offset);
             $this->fileSize -= $offset;
             $array = unpack($format, $data);
+            if ($array['length'] == 4294967295)
+                $array['length'] = -1;
             $length = $array['length'];
             if ($length == 0)
                 continue;
A simple test case for clarity:

Code: Select all

$data = file_get_contents('testc1.bin');
$array = unpack("vreserved/Vlength/c2data", $data);
var_dump($array);

Code: Select all

$ od -t x1 testc1.bin
0000000 12 34 ff ff ff ff 56 78
0000010
Results on a 64-bit system:

Code: Select all

array(4) {
  ["reserved"]=>
  int(13330)
  ["length"]=>
  int(4294967295)
  ["data1"]=>
  int(86)
  ["data2"]=>
  int(120)
}
...nothing new because here all 64 bits are required to represent -1, and the "V" format for unpack() always yields an uint32.

Of course some non-specific 32-bit system that turned up behaves as expected:

Code: Select all

array(4) {
  ["reserved"]=>
  int(13330)
  ["length"]=>
  int(-1)
  ["data1"]=>
  int(86)
  ["data2"]=>
  int(120)
}
I do not see any similar fix in 6.3.2. You might need to review the entire dicom.php as all usage of $UNDEF_LEN near unpack() might be vulnerable.

tburba
Posts:50
Joined:Fri Apr 23, 2010 5:02 pm
Contact:

Post by tburba » Tue Jan 17, 2012 5:34 pm

Just a thought:

Code: Select all

if (PHP_INT_SIZE === 8)
    $UNDEF_LEN = 4294967295;

pacsone
Site Admin
Posts:3149
Joined:Tue Sep 30, 2003 2:47 am

Post by pacsone » Tue Jan 17, 2012 7:21 pm

That's a great catch!

We'll fix it as follows for the next version (6.3.3) of PacsOne Server:

Code: Select all

if (PHP_INT_SIZE > 4)
    $UNDEF_LEN = 4294967295;

tburba
Posts:50
Joined:Fri Apr 23, 2010 5:02 pm
Contact:

Post by tburba » Fri Nov 08, 2013 8:32 pm

I updated to 6.3.8 on the same server (now it's Debian 7.2), and the error returned:
Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 4294967296 bytes) in /home/PacsOne/php/dicom.php on line 3543
And I saw that $UNDEF_LEN is again -1. Adding the logic from earlier posts helped.

Code: Select all

--- dicom.php.ORIG      2013-11-08 21:30:59.000000000 +0200
+++ dicom.php   2013-11-08 21:50:40.000000000 +0200
@@ -22,6 +22,9 @@
 // read/write buffer size
 $MAX_PDU_LEN = 16 * 1024;
 // un-defined length
+if (PHP_INT_SIZE > 4)
+       $UNDEF_LEN = 4294967295;
+else
 $UNDEF_LEN = -1;
 // customized display texts
 global $CUSTOMIZE_PATIENT_ID;
By the way, actually you didn't add this fix in 6.3.3. I found both installers and extracted the file. Changes in dicom.php that this version brought, are related only to the "KO" modality.

pacsone
Site Admin
Posts:3149
Joined:Tue Sep 30, 2003 2:47 am

Post by pacsone » Sat Nov 09, 2013 10:54 pm

Looks like the fixes/changes didn't get merged into version 6.3.3 for some reason, so we'll have to re-merge them into the next release. Thank you very much for reporting this bug.

Post Reply