Login
You're viewing the assemblag.es public feed.
  • David Chisnall (*Now with 50% more sarcasm!*)david_chisnall@infosec.exchange
    Oct 22, 2026, 8:35 AM

    @GossiTheDog

    Regarding the rumours the PHP patches don’t fix the vulnerabilities - it’s not true, they patched the vulnerabilities of issue.

    Having reviewed their diff, I'm not sure how you can make that claim. Their fix for data corruption in out-of-memory conditions was to add explicit error handling on a huge number of code paths. A change of that level of complexity almost certainly misses error handling from one or more paths that matter. It is not a systemic fix that would address the root cause, it is a load of duck tape applied across the entire codebase.

    I think it's reasonable to claim that it fixes the specific exploit path used in the PoC but I am not at all convinced that it fixes the vulnerability.

    💬 1🔄 0⭐ 0

Replies

  • redsakanaredsakana@infosec.exchange
    Oct 22, 2026, 11:16 AM

    @david_chisnall Since the blog that describes the exploitation process recommends memory_limit = -1 (disabled) as a mitigation if patching is not possible, I was thinking whether it would make sense as a defense-in-depth measure to run with the internal memory_limit disabled all the time. Instead set up rlimits or cgroups or whatever to immediately kill off workers that hit the limit.

    I don't deal in php much and this probably isn't suited to all installations, but in theory this feels like it should eliminate a class of vulnerabilities stemming from retroactively implemented OOM recovery. @GossiTheDog

    (edit: turns out that convincing Linux to JUST KILL THE FUCKING PROCESS DO NOT SEND ENOMEM DO NOT TRY ANYTHING without resorting to LD_PRELOAD tricks is hard, setting both memory.max and memory.swap.max maybe kinda does it?)

    💬 0🔄 0⭐ 1