- CVE-2025-1218: out-of-bounds reads in the mysqlnd wire-protocol parser. A malicious or compromised MySQL server could send a truncated packet and make the client read past the end of the packet buffer. Re-implementation, against the PHP 5.3 mysqlnd sources, of upstream 114dbb74368e6a6cd6e48ddb4a76dbe8728b84e2 (GHSA-r6x9-5r99-36j7, php-8.2.34 / php-8.3.34); the upstream diff does not apply to 5.3 in any form, so every bound was re-derived from 5.3's own bookkeeping. BAIL_IF_NO_MORE_DATA, which only noticed an over-read after it had happened, is replaced by BAIL_PREMATURE_END / BAIL_IF_NOT_ENOUGH_DATA_EX, and php_mysqlnd_net_field_length()/_ll() are given the bytes still left in the packet so a length encoding can no longer be read out of bounds. Memory-safety fixes cover the greeting (its server version string ran estrdup() off a 2048-byte stack buffer with no terminator guarantee on this branch - strictly worse here than on any later branch - plus the 31-byte fixed block and the split scramble), the OK and result-set header packets, the EOF packet, the in-row EOF marker, the result-set field metadata lengths (which leaked heap bytes into user-visible column metadata), the text-protocol row field lengths and ps_fetch_time/date/datetime. The two new checks in prepare_read are HARDENING ONLY and provably cannot fire; the mysqlnd_ps.c change is a memory leak fix on the newly reachable prepare-EOF failure path, not an over-read. The auth-response, SHA256-public-key and caching-sha2 packet readers, the change-user auth-switch branch and the pluggable-auth parts of the greeting do not exist at 5.3, so those parts of the upstream fix have no target here. The 38 upstream .phpt tests are not carried - the fake_server.inc they drive needs PHP 8.0 syntax - so the C fix ships without tests - The same mysqlnd_ps.c hunk also corrects that path's result free from mnd_efree() to upstream's php-7.0 form, mnd_pefree(stmt->result, stmt->result->persistent): mysqlnd_result_init() allocates the result with mnd_pecalloc(..., persistent), so on a persistent connection the Zend allocator was being handed a malloc()ed block. Before the change a hostile prepare over p:127.0.0.1 aborts with "zend_mm_heap corrupted" on a build with the Zend MM heap checks compiled in; after it the same run completes, and a non-persistent connection is unaffected either way - Also fixes a pre-existing use-after-free on the row-reader failure path: the CVE-2024-8929 error loops free every field decoded so far without clearing the zvals, and the result set frees them again at teardown. All 2 sites now clear after freeing. Confirmed under AddressSanitizer with the Zend allocator disabled - heap-use-after-free before, clean after, on the three new short-length tests and the nine CVE-2024-8929 stmt-row tests. Upstream still carries the same loops unguarded in php-8.2.34 through php-8.5.11 - mysqlnd: initialise every pre-allocated row field before decoding (php-5.3.29-mysqlnd-rowp-init-fields.patch). The row readers pre-allocate a zval per column with MAKE_STD_ZVAL(), which sets no type, and only type it when the decode loop reaches that column; the CVE-2024-8929 error paths abandon a row part-way, leaving the rest allocated but never typed, and the result set still frees the whole row at teardown. Each column is now ZVAL_NULL()ed at allocation. Verified with valgrind under USE_ZEND_ALLOC=0. PHP 5 only, and kept separate from the CVE patch because the defect predates it and is reachable without it