hitoshura25/cvefixes huggingface dataset:
CVE-2016-6870 (PHP, published 2017-02-17T17:59Z)
Description: value: Out-of-bounds write in the (1) mb_detect_encoding, (2) mb_send_mail, and (3) mb_detect_order functions in Facebook HHVM before 3.15.0 allows attackers to have unspecified impact via unknown vectors.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/ext/mbstring/ext_mbstring.cpp
hphp/test/quick/mbstring-oob.php
Commit message: Use req::strndup in php_mb_parse_encoding_list to prevent oob memory write.

Summary:
Fix out of bounds write access in mb_detect_encoding.  Using strndup in
php_mb_parse_encoding_list will cause strings with embedded nulls to be
unexpectedly shortened.  The expected length of the string is tracked in
value_length but since strndup may copy fewer characters when there are
mbedded null this can lead to oob writes into tmpstr.

I've found a couple other places in this file that use strndup and replaced
them with req::strndup as well.  The use of strndup in mb_send_mail also seemed
to be a leak.

This replaces uses of strndup with req::strndup which can handle embedded
nulls properly.

It looks like I also accidentally fixed t11337047 at the same time.  Adding it to the list of tasks.

Reviewed By: paulbiss

Differential Revision: D3360065

fbshipit-source-id: 99776cf9105e3789883380bf30240009eec52cec


Vulnerable code:
      tmpstr = (char *)strndup(value+1, value_length-2);
    else
      tmpstr = (char *)strndup(value, value_length);
    free(tmpstr);
  char *encstr = strndup(encoded_string.data(), encoded_string.size());
  free(encstr);
      to_r = strndup(to.data(), to_len);

Fixed code:
      tmpstr = req::strndup(value + 1, value_length - 2);
    } else {
      tmpstr = req::strndup(value, value_length);
    req::free(tmpstr);
  char *encstr = req::strndup(encoded_string.data(), encoded_string.size());
  req::free(encstr);
      to_r = req::strndup(to.data(), to_len);
  if (to_r != to.data()) {
    req::free(to_r);
  }
<?hh // strict
// Copyright 2004-present Facebook. All Rights Reserved.

$var0 = null;
$var3 = "\x00";
$var3 = mb_detect_encoding($var0,$var3);
CVE-2016-6871 (PHP, published 2017-02-17T17:59Z)
Description: value: Integer overflow in bcmath in Facebook HHVM before 3.15.0 allows attackers to have unspecified impact via unknown vectors, which triggers a buffer overflow.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/ext/bcmath/ext_bcmath.cpp
hphp/test/slow/ext_bcmath/bccomp_overflow.php
hphp/test/slow/ext_bcmath/bccomp_overflow.php.expect
Commit message: Fix buffer overrun due to integer overflow in bcmath

Summary: scale gets passed around as an int inside the library.

Reviewed By: mxw

Differential Revision: D3624520

fbshipit-source-id: d39927413cec24fda2e475a296ad5d9019ccef0a


Vulnerable code:
  if (scale < 0) scale = BCG(bc_precision);
  if (scale < 0) scale = BCG(bc_precision);
  if (scale < 0) scale = BCG(bc_precision);
  if (scale < 0) scale = BCG(bc_precision);
  if (scale < 0) scale = BCG(bc_precision);
  if (scale < 0) scale = BCG(bc_precision);
  if (scale < 0) scale = BCG(bc_precision);
  if (scale < 0) scale = BCG(bc_precision);

Fixed code:
static int64_t adjust_scale(int64_t scale) {
  if (scale < 0) {
    scale = BCG(bc_precision);
    if (scale < 0) scale = 0;
  }
  if ((uint64_t)scale > StringData::MaxSize) return StringData::MaxSize;
  return scale;
}

  scale = adjust_scale(scale);
  scale = adjust_scale(scale);
  scale = adjust_scale(scale);
  scale = adjust_scale(scale);
  scale = adjust_scale(scale);
  scale = adjust_scale(scale);
  scale = adjust_scale(scale);
  scale = adjust_scale(scale);
<?php

$intMaxPre = PHP_INT_MAX - 1;
$stringNormal = 'abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ';

$number_bccomp_10 = bccomp("2015.5", $stringNormal, $intMaxPre);
var_dump($number_bccomp_10);
int(1)
CVE-2016-6872 (PHP, published 2017-02-17T17:59Z)
Description: value: Integer overflow in StringUtil::implode in Facebook HHVM before 3.15.0 allows attackers to have unspecified impact via unknown vectors.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/base/string-util.cpp
hphp/test/slow/string_length_overflow/implode.php
hphp/test/slow/string_length_overflow/implode.php.expectf
Commit message: Fix integer overflow in StringUtil::implode

Reviewed By: ricklavoie

Differential Revision: D3623922

fbshipit-source-id: 136d124a850c07cc6c63535afc11d36499d576fc


Vulnerable code:
  int len = 0;
  int lenDelim = delim.size();

Fixed code:
  size_t len = 0;
  size_t lenDelim = delim.size();
<?php

$stringLarge = str_repeat('*', 300289);
$arrayLarge = array_fill(0, 49981, '*');
$string_implode_2 = implode($stringLarge, $arrayLarge);

Fatal error: String length exceeded 2^31-2: 15008494201 in %s/test/slow/string_length_overflow/implode.php on line 5
CVE-2016-6873 (PHP, published 2017-02-17T17:59Z)
Description: value: Self recursion in compact in Facebook HHVM before 3.15.0 allows attackers to have unspecified impact via unknown vectors.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: NVD-CWE-Other \u2014 Other
NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/ext/array/ext_array.cpp
hphp/test/slow/array_functions/self_recursive.php
hphp/test/slow/array_functions/self_recursive.php.expectf
Commit message: Fix self recursion in compact

Summary: There were no checks at all.

Reviewed By: alexmalyshev

Differential Revision: D3623763

fbshipit-source-id: 9d708deca05bbd121503e8f323b4f295fde8e835


Vulnerable code:
static bool couldRecur(const Variant& v, const Array& arr) {
    arr.get()->kind() == ArrayData::kGlobalsKind ||
    arr.get()->kind() == ArrayData::kProxyKind;
                                couldRecur(v, subarr1),
        php_array_replace_recursive(seen, couldRecur(v, subarr1),
static void compact(VarEnv* v, Array &ret, const Variant& var) {
    for (ArrayIter iter(var.getArrayData()); iter; ++iter) {
      compact(v, ret, iter.second());
    compact(v, ret, varname);
    compact(v, ret, args);
    compact(v, ret, varname);
    compact(v, ret, args);


Fixed code:
static bool couldRecur(const Variant& v, const ArrayData* arr) {
    arr->kind() == ArrayData::kGlobalsKind ||
    arr->kind() == ArrayData::kProxyKind;
                                couldRecur(v, subarr1.get()),
        php_array_replace_recursive(seen, couldRecur(v, subarr1.get()),
static void compact(PointerSet& seen,
                    VarEnv* v, Array &ret, const Variant& var) {
    auto adata = var.getArrayData();
    auto check = couldRecur(var, adata);
    if (check && !seen.insert(adata).second) {
      raise_warning("compact(): recursion detected");
      return;
    for (ArrayIter iter(adata); iter; ++iter) {
      compact(seen, v, ret, iter.secondRef());
    }
    if (check) seen.erase(adata);
    PointerSet seen;
    compact(seen, v, ret, varname);
    if (!args.empty()) compact(seen, v, ret, args);
    PointerSet seen;
    compact(seen, v, ret, varname);
    if (!args.empty()) compact(seen, v, ret, args);
  var_dump(compact($a));

Warning: compact(): recursion detected in %s/test/slow/array_functions/self_recursive.php on line 18
array(0) {
}
CVE-2018-6340 (C++, published 2018-12-31T22:29Z)
Description: value: The Memcache::getextendedstats function can be used to trigger an out-of-bounds read. Exploiting this issue requires control over memcached server hostnames and/or ports. This affects all supported versions of HHVM (3.30 and 3.27.4 and below).
Severity: MEDIUM (CVSS v3 base score: 8.1)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/ext/memcache/ext_memcache.cpp
Commit message: CVE-2018-6340 Fix buffer overread

Summary:
snprintf() returns the number of would be written bytes if the buffer had
enough size, letting the original code to construct output string from
arbitrary data on the stack.

Fix this by properly assembling the String without trying to arbitrarily
limiting the length to 30 bytes.

Reviewed By: ottoni

Differential Revision: D13509547

fbshipit-source-id: aa401b83d356f5b261433c4b16d777948ba7f9b4


Vulnerable code:
    char stats_key[30] = {0};
    size_t key_len;

    key_len = snprintf(stats_key, sizeof(stats_key), "%s:%d", hostname, port);

    return_val.set(String(stats_key, key_len, CopyString), server_stats);

Fixed code:
    auto const port_str = folly::to<std::string>(port);
    auto const key_len = strlen(hostname) + 1 + port_str.length();
    auto key = String(key_len, ReserveString);
    key += hostname;
    key += ":";
    key += port_str;
    return_val.set(key, server_stats);
CVE-2018-6345 (PHP, published 2019-01-15T22:29Z)
Description: value: The function number_format is vulnerable to a heap overflow issue when its second argument ($dec_points) is excessively large. The internal implementation of the function will cause a string to be created with an invalid length, which can then interact poorly with other functions. This affects all supported versions of HHVM (3.30.1 and 3.27.5 and below).
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/base/zend-string.cpp
hphp/test/slow/string/number_format_error.php
hphp/test/slow/string/number_format_error.php.expect
Commit message: Fix a bug in number_format()

Summary: In case of error while calling snprintf, return empty string instead of malformed string.

Reviewed By: binliu19

Differential Revision: D13379372

fbshipit-source-id: 1e5611598464daccc674d5a96558c9f2aee08fc8


Vulnerable code:

Fixed code:
  if (tmplen < 0) return empty_string();
    if (tmplen < 0) return empty_string();
<?php
  $READ_LENGTH = 0x1000; // choose leak size
// construct fake iptc header for controlled read
$iptc_hdr =
  "\x1c\x01" . // magic
  "\x00\x80" . // dataset, recnum
  "\x00" .     // padding
  pack("N", $READ_LENGTH);
// spray a bit so it's near the broken string
$holder = [];
for($i = 0; $i < 100; $i++)
  $holder[] = str_pad($iptc_hdr, 96);
// trigger bug to create string with len=-1
$badstr = number_format(0,0x7fffffff);
var_dump($badstr);
// leak memory :)
$tmp = iptcparse($badstr);
var_dump($tmp);
?>
string(0) ""
bool(false)
CVE-2019-11925 (PHP, published 2019-09-06T19:15Z)
Description: value: Insufficient boundary checks when processing the JPEG APP12 block marker in the GD extension could allow access to out-of-bounds memory via a maliciously constructed invalid JPEG input. This issue affects HHVM versions prior to 3.30.9, all versions between 4.0.0 and 4.8.3, all versions between 4.9.0 and 4.15.2, and versions 4.16.0 to 4.16.3, 4.17.0 to 4.17.2, 4.18.0 to 4.18.1, 4.19.0, 4.20.0 to 4.20.1.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/ext/gd/ext_gd.cpp
hphp/test/slow/ext_gd/exifreaddata_APP12.php
hphp/test/slow/ext_gd/exifreaddata_APP12.php.expectf
Commit message: exif_process_APP12: Fix length calculation for second tag to prevent information leak

Summary:
buffer + 2+l1+1 points to the second tag. The maximum length of the buffer is length. Hence, the max length of the tag is length - (2+l1+1). Instead, the length passed is length - 2 - l1 + 1 which leads to a 2 byte overflow. If the last character of buffer is not null, this would lead to an out of bounds read of size 2.

Fixes CVE-2019-11925

Reviewed By: fredemmott

Differential Revision: D16930333

fbshipit-source-id: aad9cccaef3c678abc53bfd549aff6b582082a90


Vulnerable code:
      l2 = php_strnlen(buffer+2+l1+1, length-2-l1+1);

Fixed code:
      l2 = php_strnlen(buffer+2+l1+1, length-2-l1-1);
<?hh

<<__EntryPoint>>
function main_exifreaddata() {
  $jpeg = "\xff\xd8\xec\x00\x05\x58\x00\x17";
  $data_stream = "data://text/plain;base64," . base64_encode($jpeg);
  var_dump(exif_read_data($data_stream));
}
Warning: File structure corrupted in %s/ext_gd/exifreaddata_APP12.php on line 7

Warning: Invalid JPEG file in %s/ext_gd/exifreaddata_APP12.php on line 7
bool(false)
CVE-2019-11926 (PHP, published 2019-09-06T19:15Z)
Description: value: Insufficient boundary checks when processing M_SOFx markers from JPEG headers in the GD extension could allow access to out-of-bounds memory via a maliciously constructed invalid JPEG input. This issue affects HHVM versions prior to 3.30.9, all versions between 4.0.0 and 4.8.3, all versions between 4.9.0 and 4.15.2, and versions 4.16.0 to 4.16.3, 4.17.0 to 4.17.2, 4.18.0 to 4.18.1, 4.19.0, 4.20.0 to 4.20.1.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/ext/gd/ext_gd.cpp
hphp/test/slow/ext_gd/exifreaddata.php
hphp/test/slow/ext_gd/exifreaddata.php.expectf
Commit message: exif_scan_JPEG_header: Added length check to prevent information leak

Summary:
'exif_process_SOFn' assumes that the JPEG header has at least 6 length. On providing a length < 6, this leads to an out of bounds heap read.

Fixes CVE-2019-11926

Reviewed By: fredemmott

Differential Revision: D16927050

fbshipit-source-id: 76c4b7c95acbb7852b0435298613d559d94e7270


Vulnerable code:

Fixed code:
        if ((itemlen - 2) < 6) {
          return 0;
        }

<?hh

<<__EntryPoint>>
function main_exifreaddata() {
  $jpeg = "\xff\xd8\xc9\x00\x03\x04\x03\xf8";
  $data_stream = "data://text/plain;base64," . base64_encode($jpeg);
  var_dump(exif_read_data($data_stream));
}
Warning: Invalid JPEG file in %s/ext_gd/exifreaddata.php on line 7
bool(false)
CVE-2019-11929 (PHP, published 2019-10-02T19:15Z)
Description: value: Insufficient boundary checks when formatting numbers in number_format allows read/write access to out-of-bounds memory, potentially leading to remote code execution. This issue affects HHVM versions prior to 3.30.10, all versions between 4.0.0 and 4.8.5, all versions between 4.9.0 and 4.18.2, and versions 4.19.0, 4.19.1, 4.20.0, 4.20.1, 4.20.2, 4.21.0, 4.22.0, 4.23.0.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/base/zend-string.cpp
hphp/test/slow/string/number_format_t53795309.php
hphp/test/slow/string/number_format_t53795309.php.expect
Commit message: string_number_format: Correctly handles return value of snprintf

Summary: `snprintf` can return a value greater than the number of bytes copied. In case the first byte of the string is not a digit (could be '-'), size of `tmpstr` was being updated without checking `tmplen`. This resulted in either an assertion error or a heap overflow depending on whether the assertion is compiled or not.

Reviewed By: mofarrell, qianxuweiren

Differential Revision: D17327899

fbshipit-source-id: ee53875d21e02608c6d870388eecf1464de24ff1


Vulnerable code:
  if (tmpbuf == nullptr || !isdigit((int)tmpbuf[0])) {

Fixed code:
  // This actually means 63 bytes for characters + 1 byte for '\0'
  // From the man page of snprintf, the return value is:
  // The number of characters that would have been written if n had been
  // sufficiently large, not counting the terminating null character.
  if (tmplen < 64 && (tmpbuf == nullptr || !isdigit((int)tmpbuf[0]))) {
<?hh
// Copyright 2004-present Facebook. All Rights Reserved.

<<__EntryPoint>>
function main() {
  $bin_repr = "\x00\x00\x00\x00\x00\x00\x00\x80";
  $double_num = unpack("dnum", $bin_repr)['num'];
  var_dump(number_format($double_num, 100));
}
string(103) "-0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
CVE-2019-11930 (PHP, published 2019-12-04T17:16Z)
Description: value: An invalid free in mb_detect_order can cause the application to crash or potentially result in remote code execution. This issue affects HHVM versions prior to 3.30.12, all versions between 4.0.0 and 4.8.5, all versions between 4.9.0 and 4.23.1, as well as 4.24.0, 4.25.0, 4.26.0, 4.27.0, 4.28.0, and 4.28.1.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-763 \u2014 Release of Invalid Pointer or Reference
The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/ext/mbstring/ext_mbstring.cpp
hphp/test/slow/ext_mb/mb_detect_order_t54638796.php
hphp/test/slow/ext_mb/mb_detect_order_t54638796.php.expect
Commit message: ext_mbstring: Fix invalid free() in php_mb_parse_encoding

Summary:
A chunk of memory allocated by 'req::calloc_noptrs' was being freed by 'free'. The former internally calls 'calloc' and returns a pointer at an index sizeof(MallocNode) inside the allocated buffer. This led to freeing invalid memory.

CVE-2019-11930

Reviewed By: jjergus

Differential Revision: D18179908

fbshipit-source-id: 0e3fe77628e0b9dee8361e712b8abac59ae5ed22


Vulnerable code:
      free(*return_list);

Fixed code:
      req::free(*return_list);
<?hh
// Copyright 2004-present Facebook. All Rights Reserved.

<<__EntryPoint>>
function main() {
  var_dump(mb_detect_order("UTF-8,\x2c"));
}
bool(false)
CVE-2019-11935 (PHP, published 2019-12-04T17:16Z)
Description: value: Insufficient boundary checks when processing a string in mb_ereg_replace allows access to out-of-bounds memory. This issue affects HHVM versions prior to 3.30.12, all versions between 4.0.0 and 4.8.5, all versions between 4.9.0 and 4.23.1, as well as 4.24.0, 4.25.0, 4.26.0, 4.27.0, 4.28.0, and 4.28.1.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-120 \u2014 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/ext/mbstring/ext_mbstring.cpp
hphp/test/zend/good/ext/mbstring/mb_ereg_replace_invalid_replacement.php
hphp/test/zend/good/ext/mbstring/mb_ereg_replace_invalid_replacement.php.expectf
Commit message: Fix buffer overflow in mb_ereg_replace

Summary:
This diff has already been landed to release and to open-source branches. We're now landing it on master.

CVE-2019-11935

Reviewed By: jjergus

Differential Revision: D18177934

fbshipit-source-id: d108a59e38c67f5f5e835febd7255307605ba62c


Vulnerable code:
        if ((replacement.size() - i) >= 2 && fwd == 1 &&
          p[0] == '\\' && p[1] >= '0' && p[1] <= '9') {
        } else {

Fixed code:
        auto const remaining = replacement.size() - i;
        if (remaining >= 2 && fwd == 1 &&
            p[0] == '\\' && p[1] >= '0' && p[1] <= '9') {
        } else if (remaining >= fwd) {
        } else {
          raise_warning("Replacement ends with unterminated %s: 0x%hhx",
                        enc->name, *p);
          break;
<?hh

<<__EntryPoint>>
function main(): void {
  var_dump(mb_ereg_replace("", "\xf1", "", ""));
  throw new Error("done");
}
Warning: Replacement ends with unterminated UTF-8: 0xf1 in %s/mb_ereg_replace_invalid_replacement.php on line 5
string(0) ""

Fatal error: Uncaught Error: done in %s/mb_ereg_replace_invalid_replacement.php:6
Stack trace:
#0 (): main()
#1 {main}
CVE-2019-3557 (C++, published 2019-01-15T22:29Z)
Description: value: The implementations of streams for bz2 and php://output improperly implemented their readImpl functions, returning -1 consistently. This behavior caused some stream functions, such as stream_get_line, to trigger an out-of-bounds read when operating on such malformed streams. The implementations were updated to return valid values consistently. This affects all supported versions of HHVM (3.30 and 3.27.4 and below).
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/facebook/hhvm
Files changed:
hphp/runtime/base/output-file.cpp
hphp/runtime/ext/bz2/bz2-file.cpp
hphp/test/slow/oob_read_file.php
hphp/test/slow/oob_read_file.php.expectf
Commit message: CVE-2019-3557: Fix OOB read in readRecord on BZ2Files/OutputFiles

Summary:
These File subclasses return -1 on read errors which is not what is
expected for readImpl--this made File::readRecord behave unusually if the read
fails, causing it to read (size_t)(-1) bytes from its stream buffer; which,
unsurprisingly produces a out-of-bounds heap read.

Reviewed By: leikahing, jjgriego

Differential Revision: D13659395

fbshipit-source-id: 359ed6e3ff9f9cf49b752b666f51c4e0b3ce4b8a


Vulnerable code:
  return -1;
      return -1;

Fixed code:
  return 0;
      return 0;
<?hh

<<__EntryPoint>>
function main() {
    $a = bzopen("/dev/null", "w");
    $tmp = stream_get_line($a, 1, "1");
    var_dump($tmp);

    $a = fopen("php://output", "w");
    $tmp = stream_get_line($a, 1, "1");
    var_dump($tmp);
}
string(0) ""

Warning: cannot read from a php://output stream in %s on line %d
string(0) ""