aurupdater

php85

STATUS (2026-10-24): abandoned, does not exist in arch/adapted/. Never committed to git (confirmed via git log --all -- adapted/php85 returning nothing, and adapted/README not listing it) – superseded same day (2026-10-21) by [[php]], which forks official Arch php 8.5.12 (fix already included upstream, no patch needed) and adds armv7h. Everything below is kept for the historical record of why that pivot happened, but don’t expect the directory/PKGBUILD to actually be there.

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.