[3.14] gh-90949: add Expat API to prevent XML deadly allocations (CVE-2025-59375) (GH-139234)

[picnixz]

Expose the XML Expat 2.7.2 mitigation APIs to disallow use of disproportional amounts of dynamic memory from within an Expat parser (see CVE-2025-59375 for instance).

The exposed APIs are available on Expat parsers, that is, parsers created by xml.parsers.expat.ParserCreate(), as:

• parser.SetAllocTrackerActivationThreshold(threshold), and
• parser.SetAllocTrackerMaximumAmplification(max_factor).

(cherry picked from commits f04bea4 and 68a1778)

• Issue: Expose Expat XML attack protection APIs #90949

---

📚 Documentation preview 📚: https://cpython-previews--139359.org.readthedocs.build/

[picnixz]

I'll wait until gh-139366 is merged to ease future backports

[hartwork]

I'll wait until gh-139366 is merged to ease future backports

@picnixz if I'm not mistaken, it's both merged and cherry-picked to this PR (as the third commit) by now. What would be the next steps for this pull request?

[picnixz]

A core developer needs to review it, and the release manager needs to approve it because we're in RC3 phase. I really want at least two core devs to check this PR to be sure I didn't mess the backports. I didn't backport the docs changes that will be added in the next one (the one for billion laughs).

[hartwork]

@picnixz so the plan is to first get review from Gregory and only then Hugo, I see 👍

[picnixz]

I would be happy if you could also review it as you're an expert here as well :')

[hartwork]

I would be happy if you could also review it as you're an expert here as well :')

@picnixz done, looks good 👍

My method of review has been comparing (1) the diff of #139234 against main with (2) the diff in here. What I found was no difference but:

• Doc/whatsnew/3.15.rst on main side but not 3.14 (as expected)
• @permit_long_* on main side but not 3.14 (as expected)

The tools I used for this were git rebase -i, git diff and Meld.

So if #139234 was alright (which I believe) then very likely this is, too 👍

[picnixz]

Thank you for the review. I'll let Gregory have a look and then Hugo can hit merge I think (only he can merge during RC phase).

For the other branches, I would suggest you continue your branch for 3.13 with the latest stuff (or try to directly cherry-pick this specific PR with a new one). I think we should be able to backport this PR to 3.13 directly without too many conflicts (I hope).

[gpshead]

FWIW when to merge this is up to the release manager (hugovk). As we're treating it as a security mitigation feature similar to past such things and adding it to older releases as well, that suggests letting this wait for 3.14.1 is fine.

[picnixz]

Note for the RM: we have a UAF in all branches, independently of Expat version: See #139400. So I would prefer that this one is not backported until we fix it. On 3.14 we don't see the crash, but on 3.13 (and probably on older branches), we will also see it. I believe we are able not to crash by chance due to some magic in incremental GC.

[hartwork]

Note for the RM: we have a UAF in all branches, independently of Expat version: See #139400.

…and a WIP candidate fix at #139403.

On 3.14 we don't see the crash, but on 3.13 (and probably on older branches), we will also see it. I believe we are able not to crash by chance due to some magic in incremental GC.

@picnixz In my tests on another notebook I saw two other branches affected directly and once we add del parent_parser all branches are. I'm with you that changes in the garbage collector could take part in 3.14 and main behaving slightly differently.

[picnixz]

We will merge this one in 3.14.1 (3.14 is now ongoing its release process). To have a good synchronization, we'll also delay 3.10 to 3.13 backports for their next release cycle.

[picnixz]

I'm going to work on merging the deadly allocation PR now. Sorry for the delay but I got very busy with my new work & IRL

[picnixz]

Ok, so here's the plan:

• There are slight mistakes in the docs for this PR that were later corrected in gh-90949: expose Expat API to tune exponential expansion protections #139368.
• I will keep those slight wording mistakes because it would complicate the backport of gh-90949: expose Expat API to tune exponential expansion protections #139368 otherwise...

@hartwork Can you check your existing PRs please? I think it'd be fine to actually merge the 3.10-3.14 ones and their backports as we have roughly 2 months until the next release.

[hartwork]

I will keep those slight wording mistakes because it would complicate the backport

@picnixz yes please, a backport is not the place to fix up on the original as far as I am concerned.

@hartwork Can you check your existing PRs please?

I believe I got them all into mergable shape and they just need a re-trigger of CI — the read-the-docs one is flaky — to be green and ready. I am missing something? Anything in particular that you'd want me to check or re-check for?

I think it'd be fine to actually merge the 3.10-3.14 ones and their backports as we have roughly 2 months until the next release.

Cool!

[hartwork]

I'm going to work on merging the deadly allocation PR now. Sorry for the delay but I got very busy with my new work & IRL

@picnixz thank you! 🙏

[hartwork]

@hartwork Can you check your existing PRs please?

@picnixz they all end in commit "Drop workaround for 139400 as no-longer-needed" and their commits tell the same story. I'm happy to fix anything that needs fixing, but I believe they're all ready and have been.

[picnixz]

Perfect, I'm going to merge them all and then we'll move on to adding the other API (with the docs amendments)