* SECURITY UPDATE: out-of-bounds read in the convert stream filters when line-break-chars contains a NUL byte - debian/patches/php-5.2-CVE-2026-92842.patch: backport upstream commit b4e3397ec8f4f647e6e019dbf79870fc2f14ba78 so php_conv_base64_encode_ctor(), php_conv_qprint_encode_ctor() and php_conv_qprint_decode_ctor() in ext/standard/filters.c duplicate lbchars with pestrndup(lbchars, lbchars_len, persistent) instead of the strlen-based pestrdup(). pestrdup() truncated at the first NUL while inst->lbchars_len kept the untruncated length, so the converters read past the end of the allocation. The option is reachable from userspace through stream_filter_append() and php://filter. Also adds upstream's ext/standard/tests/filters/ghsa-88hq-2827-7pg6.phpt, adapted for 5.2 (array() instead of the short-array literal). - CVE-2026-92842 * SECURITY UPDATE: integer overflow in the ext/soap chunked-transfer body accumulator - debian/patches/php-5.2-CVE-2025-14181.patch: backport upstream commit b11bd1d9390bb203684e3d4aa5e1104ea842de6f to ext/soap/php_http.c. The "if (http_buf_size + buf_size + 1 < 0)" test in get_http_body() is dead code - signed overflow is undefined - so a malicious endpoint could answer with Transfer-Encoding: chunked and chunk sizes totalling more than INT_MAX, wrap the accumulator negative and overflow the heap buffer. http_buf_size becomes size_t, buf_size and len_size become unsigned int, and each growth step is bounded with "buf_size >= (size_t) INT_MAX - http_buf_size" before the addition is performed. INT_MAX rather than upstream's ZSTR_MAX_LEN because this branch has no zend_string: the body is a char* grown with erealloc() and its length leaves the function through an int *out_size. The Content-Length path gains "header_length >= INT_MAX" and the Connection: close path gains the matching bound on its 4096-byte steps. The Location: redirect allocation upstream hardens in the same commit becomes safe_emalloc(1, p - t, strlen(new_url->path) + 2), 5.2's equivalent of zend_string_safe_alloc(). The upstream .phpt is not carried: it drives a live http endpoint through a server.inc helper this tree does not have and needs 4 GB of RAM. - CVE-2025-14181 * SECURITY UPDATE: phar tar entry injection via unrepresentable entry sizes and data-carrying entry types - debian/patches/php-5.2-CVE-2026-6103.patch: backport upstream commit 0994e2e887cd993866b5e4d7dba2fade5caeefec to ext/phar/tar.c and ext/phar/phar_internal.h from the bundled PECL phar-2.0.0 tarball, which prep_build unpacks into ext/phar before any patch runs. A new phar_tar_size() rejects sizes that cannot be represented - octal that overflows, GNU base-256, non-octal digits, trailing garbage - instead of letting phar_tar_number() wrap them, GNU long link ('K') records are refused rather than registered as entries, and a new phar_tar_type_has_data() makes every entry type that carries data have its data blocks skipped. Without these the stream was left pointing at attacker-chosen bytes inside another entry's data, which phar then parsed as a tar header, so the archive presented entries that no conforming tar reader sees. phar_tar_size() checks the multiply-add at each digit rather than accumulating in uint64_t, which is not guaranteed to exist on this branch. Also adds upstream's three ext/phar/tests/tar/GHSA-j3wh-g957-2m85-*.phpt, adapted for 5.2 (array(), dirname(__FILE__), --SKIPIF-- instead of --EXTENSIONS--). - CVE-2026-6103 * SECURITY UPDATE: unbounded recursion in ext/soap XML parsing and decoding - debian/patches/php-5.2-CVE-2026-91765.patch: backport upstream commit 3655b79c7bfa90db004d75a3b282ed0f538f4836 to ext/soap/php_xml.c, php_encoding.c, php_soap.h and soap.c. ext/soap parses the request and the response with XML_PARSE_HUGE, which disables libxml2's own limit, and then recursed once per nesting level in cleanup_xml_node(), in get_node_with_attribute_recursive_ex() and through the to_zval() decode chain, so a few thousand levels exhausted the C stack. Both php_xml.c walks become iterative, documents deeper than SOAP_MAX_XML_DEPTH (2048) are rejected on libxml2 below 2.13, and an unsigned int decode_depth added to the soap module globals caps the decode chain at SOAP_MAX_DECODE_DEPTH - which also bounds href chains and cycles, since those walk the same recursion over a flat document. The counter is zeroed by encode_reset_ns()/encode_finish(), which bracket decoding on both the server and the client path. Also adds two of upstream's three ext/soap/tests/GHSA-rgrp-mwpx-f6rm*.phpt, the href-chain and href-cycle ones, adapted for 5.2. The third, the XML-depth one, is not carried: soap_xmlParseFile() on this branch never sets XML_PARSE_HUGE - only soap_xmlParseMemory() does - so libxml2 rejects its WSDL fixtures at its own xmlParserMaxDepth of 256, well before the 2048 cap the fix adds, and no fixture can both parse here and reach the check. - CVE-2026-91765