Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
picnixz merged 9 commits intopython:3.14frompicnixz:backport-f04bea4-3.14
Nov 2, 2025

Conversation

@picnixz
Copy link
Member

@picnixzpicnixz commentedSep 26, 2025•
edited
Loading

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

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

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

(cherry picked from commitsf04bea4 and68a1778)

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

CVE-2025-59375) (pythonGH-139234)Expose the XML Expat 2.7.2 mitigation APIs to disallow use ofdisproportional amounts of dynamic memory from within an Expatparser (seeCVE-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 commitf04bea4)Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
@picnixz
Copy link
MemberAuthor

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

@picnixzpicnixz marked this pull request as draftSeptember 26, 2025 16:23
@picnixz

This comment was marked as resolved.

…on API (python#139366)Fix some typos left inf04bea4,and simplify some internal functions to ease maintenance of futuremitigation APIs.
@picnixzpicnixz marked this pull request as ready for reviewSeptember 28, 2025 11:25
@hartwork
Copy link
Contributor

I'll wait untilgh-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
Copy link
MemberAuthor

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 reacted with thumbs up emoji

@hartwork
Copy link
Contributor

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

@picnixz
Copy link
MemberAuthor

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

Copy link
Contributor

@hartworkhartwork left a comment•
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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 againstmain with (2) the diff in here. What I found was no difference but:

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

The tools I used for this weregit rebase -i,git diff andMeld.

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

@picnixz
Copy link
MemberAuthor

picnixz commentedSep 28, 2025•
edited
Loading

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). Ithink we should be able to backport this PR to 3.13 directly without too many conflicts (I hope).

hartwork reacted with thumbs up emoji

@gpshead
Copy link
Member

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
Copy link
MemberAuthor

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
Copy link
Contributor

hartwork commentedSep 30, 2025•
edited
Loading

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 adddel parent_parser all branches are. I'm with you that changes in the garbage collector could take part in 3.14 andmain behaving slightly differently.

@picnixz
Copy link
MemberAuthor

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
Copy link
MemberAuthor

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

hartwork reacted with hooray emoji

@picnixz
Copy link
MemberAuthor

Ok, so here's the plan:

@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
Copy link
Contributor

hartwork commentedOct 26, 2025•
edited
Loading

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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
MemberAuthor

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

hartwork reacted with hooray emoji

@picnixzpicnixzenabled auto-merge (squash)November 2, 2025 09:08
@picnixzpicnixz merged commitbf2865f intopython:3.14Nov 2, 2025
47 checks passed
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@gpsheadgpsheadgpshead approved these changes

+1 more reviewer

@hartworkhartworkhartwork approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

@picnixzpicnixz

Labels

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@picnixz@hartwork@gpshead
[8]ページ先頭
©2009-2025 Movatter.jp