* SECURITY UPDATE: heap over-read in the convert stream filters when line-break-chars contains a NUL byte - debian/patches/php-7.0-CVE-2026-92842.patch: the base64-encode, quoted-printable-encode and quoted-printable-decode filter constructors duplicated the user-supplied line-break-chars option with pestrdup(), which stops at the first NUL, while keeping the option's real length in inst->lbchars_len. Every memcpy() of lbchars_len bytes in the filter body then read past the end of the allocation. They now duplicate with pestrndup() so the allocation matches the recorded length. Adds the upstream regression test - CVE-2026-92842 * SECURITY UPDATE: buffer overflow in the SOAP client when reading a chunked HTTP response - debian/patches/php-7.0-CVE-2025-14181.patch: get_http_body() tracked the accumulated body length in a signed int and guarded each growth step with "http_buf_size + buf_size + 1 < 0" - signed overflow, which is undefined and cannot describe an overflow of the size_t the allocator receives. A hostile SOAP endpoint answering with Transfer-Encoding: chunked could drive the total past INT_MAX, wrap the reallocation length and make the following read write out of bounds. The accumulator is now a size_t, every growth step is bounded against ZSTR_MAX_LEN before it happens, and the chunked path reallocates through zend_string_safe_realloc(). The redirect-path allocation in the same upstream commit goes through safe_emalloc() - CVE-2025-14181 * SECURITY UPDATE: tar entry injection in ext/phar - debian/patches/php-7.0-CVE-2026-6103.patch: phar_parse_tarfile() read an entry's size with phar_tar_number(), which overflows a 32-bit accumulator without a check and silently stops at the first non-octal byte, and it skipped an entry's data blocks only for typeflag '\0' and TAR_FILE. A size field that overflows, uses GNU base-256 encoding or carries trailing garbage - or an entry type that carries data but was not skipped - left the stream on attacker-controlled payload that was then parsed as the next tar header, so PHP saw a different archive from every other tar implementation. Sizes that cannot be parsed or represented are now rejected, the unsupported GNU long link record is refused instead of being registered as an entry, the "././@LongLink" name is bounded by the size of the archive, and the data blocks of every entry type that carries data are skipped. Adds the three upstream regression tests - CVE-2026-6103 * SECURITY UPDATE: stack exhaustion in ext/soap on deeply nested XML - debian/patches/php-7.0-CVE-2026-91765.patch: cleanup_xml_node() and get_node_with_attribute_recursive_ex() walked parsed documents with self-recursive C functions and master_to_zval_int() re-entered itself for every nested element and every hop of an href chain, none of them bounded - and ext/soap sets XML_PARSE_HUGE, which removes the depth limit libxml2 would otherwise apply. A SOAP request or WSDL a few thousand levels deep, an href chain, or an array element referencing its own array exhausted the C stack and crashed the process. Both tree walks are now iterative, documents nested deeper than SOAP_MAX_XML_DEPTH are rejected on libxml2 versions that enforce no limit of their own, and the decoder is capped by a per-request depth counter reset at the start and end of every encode/decode cycle. Adds the three upstream regression tests - CVE-2026-91765