aurupdater

php85

Build times (auto-updated)

Category: adapted (new package, created 2026-10-21 – vendored from AUR’s php85 by maintainer el_aur, part of the same arch-phpbs-generated family as [[php74]]). arch=() is armv6h/armv7h/aarch64 only – the whole point of adding this package is ARM coverage; x86_64/i686/pentium4 builds were deliberately left out per the user’s explicit “rebuild for ARM only” instruction. If an x86_64 need shows up later, re-derive from the current upstream AUR php85 PKGBUILD rather than just re-adding x86_64 to this one’s arch=() (upstream will have moved on by then).

Same dead-arch=()-stanza + $CARCH bug as php74 (2026-10-21)

Upstream’s arch-phpbs-generated PKGBUILD carries two arch=() assignments: an unused empty placeholder (arch=( )) early in the file, and the real one much later as the dynamic/self-resolving arch=("$CARCH") trick (meant for a build wrapper that re-invokes makepkg per target, not for direct repo_build.sh consumption). Both needed fixing, same as php74’s 2026-08-19 fix:

This dead-placeholder stanza is NOT cosmetic – it actively breaks the build. repo_build.sh’s awk-based arch parser (added 2026-09-21 to handle multi-line arch=(), see its own comment) matches the first /^arch=\(/ it finds and exits once that block closes with ) – so with two stanzas in one file, it locks onto the first (empty) one and silently falls into the “any”/x86_64-only path, never reaching the real array. Confirmed hitting this live with php74’s rebuild today: repo_release.sh logged === any (via x86_64) === and only ever built x86_64, silently skipping i686 even after the arch=() fix had supposedly been in place since 2026-08-19 (it was in the second stanza; the newer awk parser never got that far) – had to catch it from the log, fix by deleting the dead placeholder in both php74 and php85, then re-run i686 specifically via REPO_BUILD_ONLY_ARCH=i686. Any arch-phpbs-family PKGBUILD (php56 through php85) vendored in the future will have this same dead stanza – delete it on sight, don’t just fix the real array and assume that’s enough. See memory/TOOLING_NOTES.md for the general note on this parser gotcha.

CVE-2026-109618 / CVE-2026-109619 backport (2026-10-21)

Same vulnerability as [[php74]]’s entry describes (critical RCE, “php2shell”, bailout-during-OOM state corruption). Unlike the EOL 7.4/8.0/8.1 branches, PHP’s actively-maintained branches (8.2-8.5) got the fix as a normal point release (8.5.12 here) rather than a standalone EOL-style mitigation patch – there is no small, purpose-built backport patch for an older point release the way there was for 7.4.

Found the real fix commit on the PHP-8.5 branch: 31c0ea7d7ff1, “Avoid state corruption via bailout” (same core authors: arnaud-lb, iluuu1994, plus bukka/ndossche/Nicolas Grekas). It’s 423 files, because the underlying flaw is systemic – any mid-request bailout can corrupt worker-global state, not just the one multipart-upload exploit path that went public – so the real fix converts allocation call sites across ~40 extensions from “bail out on OOM” to “fail gracefully” (fallible alloc variants). This does NOT cherry-pick cleanly onto our pinned 8.5.9: there were unrelated intermediate refactors to some of the same functions between 8.5.9 and the patch’s base (confirmed e.g. ext/soap/php_http.c’s get_http_body() already uses different alloc calls/bounds-check style in 8.5.9 than the patch’s “before” context expects – a real structural conflict, not just line-offset drift).

Dry-run tested the full commit against a pristine php-8.5.9 extraction (patch -p1 --dry-run) and found genuine (non-offset) hunk failures in:

User’s explicit choice, given the above: backport the core fix only, skip the conflicting extension hardening rather than hand-resolve it. Built the actual patch file (php85-cve-2026-109618-109619.patch) with filterdiff -x '<pattern>' ... dropping all */tests/*/*.phpt files, ext/zend_test/*, run-tests.php, sapi/fuzzer/*, and the six files above – 104 files remain (down from 423), verified with a second patch -p1 --dry-run that it now applies 100% cleanly to php-8.5.9, zero fuzz, zero failures. The core exploit path survives intact: Zend/zend_alloc.c/.h, Zend/zend_execute_API.c, Zend/zend_globals.h, main/SAPI.c, main/php_variables.c, main/rfc1867.c (the actual public PoC vector) are all in the trimmed patch.

Known gap, by design: SOAP’s get_http_body(), the date parser, and the three ext/filter/ext/spl/ext/standard call sites are left exactly as exploitable to the systemic bailout-corruption class as they were before this patch (no worse, just not hardened to 8.5.12 parity). If a future public PoC specifically targets one of those paths, this package needs a real second look – the gap is known and intentional, not an oversight.