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

[hartwork]

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 commit f04bea4)

CC @picnixz

• Issue: Expose Expat XML attack protection APIs #90949

---

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

[picnixz]

Ah I think we cross-posted but I actually want to simplify the future backports and next PR by using another generic handler (it will ease the diff). See #139366

[hartwork]

Ah I think we cross-posted but I actually want to simplify the future backports and next PR by using another generic handler (it will ease the diff). See #139366

@picnixz I saw your message #139234 (comment) but did not expect impact on my wip 3.13 backport and not more than that fix. What should best be done with this pull request? Closing is alright with me if automation replaces my work after merge of #139366 — can it? Else I'm happy to adjust in here.

[picnixz]

Closing is alright with me if automation replaces my work after merge

I'll try to make an automated backport. If it succeeds, then good. Otherwise we'll need something else :( However, I'm surprised by the segfaults?

[picnixz]

(Segfaults could be because you didn't make clinic; and there are some directives that are not available in 3.13, see the 3.14 backport; maybe backporting the 3.14 PR would be easier actually)

[hartwork]

@picnixz I'll wait for merge of #139366 and then get back to it. (It did not segfault on my local amd64.)

[picnixz]

The address sanitizer says that there is a heap-UAF.

[hartwork]

@picnixz I have used the same technique as #139359 (review) here now to find any potential issues in the diff backported. The key thing that stands out is the difference in xmlparseobject versus PyObject and related casts, but I don't see obvious trouble there from a superficial look.

I'm attaching my three diffs if you would like to see my cross-diff comparison with your own eyes:

• diff-3-13.diff.txt
  i.e. the essence of [3.13] gh-90949: add Expat API to prevent XML deadly allocations (CVE-2025-59375) (GH-139234) #139367 against 3.13 here
• diff-3-14.diff.txt
  i.e. the essence of your [3.14] gh-90949: add Expat API to prevent XML deadly allocations (CVE-2025-59375) (GH-139234) #139359 against 3.14
• diff-main.diff.txt
  i.e. the essence of your gh-90949: add Expat API to prevent XML deadly allocations #139234 against main (or 3.15)

Looking from a different angle next…

[hartwork]

@picnixz I found that…

Two (or arguably four) tests are failing:

• test_set_maximum_amplification__fail_for_subparser
• test_set_activation_threshold__fail_for_subparser

A parser instance is being freed twice.

The minimal reproducer for Python 3.13 (but not 3.14) is this:

classUseAfterFreeCrashDemoTest(unittest.TestCase): deftest_use_after_free__crash(self): parser=expat.ParserCreate() subparser=parser.ExternalEntityParserCreate(None)

While interestingly adding del subparser works around the problem:

classNoUseAfterFreeHereTest(unittest.TestCase): deftest_use_after_free__no_crash(self): parser=expat.ParserCreate() subparser=parser.ExternalEntityParserCreate(None) delsubparser

Similarly, appending…

delsetterdelsubparserdelparser

…to both original tests in here works around the issue. My understanding is that there is an unrelated object graph issue here that makes CPython free things in the wrong order. I'll add my workaround for a green CI for the moment, create a new separate issue about that, and hope for ideas from your side about how to proceed from there.

[picnixz]

My understanding is that there is an unrelated object graph issue here that makes CPython free things in the wrong order

That's interesting. It could be the incremental GC which was deferred to Python 3.14 (https://docs.python.org/3.14/whatsnew/3.14.html#incremental-garbage-collection).

[picnixz]

Anyway, we can correctly assume that we have a UAF. Let's create a separate issue (do you want to?)

[hartwork]

Anyway, we can correctly assume that we have a UAF. Let's create a separate issue (do you want to?)

@picnixz I was already at it: #139400

[hartwork]

@picnixz I have marked this PR here as ready for review now. It's the same as yours for 3.14 — #139359 — plus the workaround for #139400.

[picnixz]

I would prefer waiting for the UAF to be fixed if it's ok for you. We usually don't like having a branch with temporary workarounds.

[hartwork]

I would prefer waiting for the UAF to be fixed if it's ok for you. We usually don't like having a branch with temporary workarounds.

@picnixz good with me, I can revert the workaround later 👍

[picnixz]

To have a good synchronization, we'll also delay 3.10 to 3.13 backports for their next release cycle (see #139359 (comment)).

[ambv]

I set DO-NOT-MERGE to avoid confusion. Unset that when you think we should be releasing this.

[picnixz]

The commit message will be

* gh-90949: add Expat API to prevent XML deadly allocations (CVE-2025-59375) (#139234) 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 commit f04bea44c37793561d753dd4ca6e7cd658137553) (cherry picked from commit 68a1778b7721f3fb853cd3aa674f7039c2a4df36) 

I'll rerun the CI

[picnixz]

@hartwork can you merge 3.13 into this backport please to trigger a CI run? and do the same for the other backports? (just hit the "update branch" button; I can't because you didn't allow maintainers to directly push on your branch)

[hartwork]

@picnixz done for 3.{10..13} just now 👍

[picnixz]

Thanks. I won't be able to merge 3.10, 3.11 and 3.12 as only the RMs can. I will review them myself because they weren't automated backports IIRC and we needed to tweak a bit things and there because of the lack of some functions (or maybe we did so in a smart way already). Anyway, I need to work on something else for today but hopefully I'll be able to review it by next week. Then, we can backport the other PRs.

[hartwork]

Thanks. I won't be able to merge 3.10, 3.11 and 3.12 as only the RMs can.

@picnixz understood, yes 👍

I will review them myself because they weren't automated backports IIRC and we needed to tweak a bit things and there because of the lack of some functions (or maybe we did so in a smart way already).

Do you want me to summarize the difference between these four backports?

Anyway, I need to work on something else for today but hopefully I'll be able to review it by next week. Then, we can backport the other PRs.

Thank you! 👍