[3.10] 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 commits f04bea4 and 68a1778)

CC @picnixz

• Issue: Expose Expat XML attack protection APIs #90949

[picnixz]

Thanks for the backport!

[picnixz]

Do we need offsetof?

[hartwork]

@picnixz we do!

For one, because it is used in:

staticPyMemberDefxmlparse_members[] ={{"intern", T_OBJECT, offsetof(xmlparseobject, intern), READONLY, NULL},{NULL} };

For two, because it is added in de690f1, the source of the backport.

[picnixz]

Hum. Why did add it? I think it was because my IDE complained at some point. Ok then.

[hartwork]

@picnixz I need to correct me earlier statement: I got the commit wrong, it's actually f04bea4 and you did not add that import there, it was already present in main and 3.14 and 3.13. So the question now seems to be whether we want to add or not add that import in the backports targetting 3.12, 3.11 and 3.10. It's the correct header but then some other header must be already pulling it in or the code would not compile already prior to these backports. I'm good with dropping or keeping that new include — what would you prefer?

[picnixz]

Try to reduce the diff as much as possible. If it works without the include then let's not add it. I think it would make better sense to remove it from 3.13 and 3.14 actually but I don't know if other files actually have an explicit or an implicit include policy...

[hartwork]

Try to reduce the diff as much as possible. If it works without the include then let's not add it.

@picnixz okay, let me try…

I think it would make better sense to remove it from 3.13 and 3.14 actually but I don't know if other files actually have an explicit or an implicit include policy...

That I would have trouble supporting. Please don't.

[hartwork]

@picnixz PS: I found…

Doc/c-api/structures.rst: (You may need to ``#include <stddef.h>`` for :c:func:`!offsetof`.) 

…and also…

Include/structmember.h:#include <stddef.h> /* For offsetof (not always provided by Python.h) */ 

in 3.12 code and that all of 3.10, 3.11, 3.12 have pyexpat.c include structmember.h but 3.13, 3.14, main do not and so these seem to rightfully contain a dedicated #include <stddef.h> for offsetof.

[hartwork]

@picnixz okay, let me try…

Update: dropped from all of 3.10, 3.11, 3.12 backports by now.

[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.

[hartwork]

@pablogsal I believe this is ready to be merged. Do you have a minute?

[picnixz]

This was this PR I wanted to check manually because we didn't have _Py_ID() access in 3.10

[hartwork]

@pablogsal do you have a minute for this? 🙏

[pablogsal]

Thanks a lot for the backport and thanks for the patience :)