Skip to content

UAF: xml.etree.ElementTree.Element.remove when concurrent mutations happen #126033

Closed

Description

@picnixz

Crash report

What happened?

A UAF in Element.remove was fixed in #68279 but one can mutate the child's list during .remove and cause an OOB crash:

import xml.etree.ElementTree as ET

class EvilElement(ET.Element):
    def __eq__(self, other):
        base.clear()
        return False

base = ET.Element('a')
base.append(EvilElement('a'))
base.append(EvilElement('a'))
base.remove(ET.Element('b'))

Attacked code:

cpython/Modules/_elementtree.c

Lines 1648 to 1656 in dc76a4a

for (i = 0; i < self->extra->length; i++) {
if (self->extra->children[i] == subelement)
break;
rc = PyObject_RichCompareBool(self->extra->children[i], subelement, Py_EQ);
if (rc > 0)
break;
if (rc < 0)
return NULL;
}

I think we need to introduce some state integer to check that there is no evil mutation (similar to what's being done for OrderedDict).

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Output from running 'python -VV' on the command line:

No response

Linked PRs

Activity

  1. ZeroIntensity commented on Oct 27, 2024

    @ZeroIntensity
    Member

    Hmm, there seem to be a lot of issues with PyObject_RichCompareBool and custom __eq__'s, right? It might be worth trying to fix things more globally there rather than on a case-by-case basis like this.

  2. picnixz commented on Oct 27, 2024

    @picnixz
    MemberAuthor

    I've roughly skimmed through the other occurrences and couldn't find UAFs or bad OOB. And I'd prefer fixing them one by one because the patch is not always the same.

  3. self-assigned this
    on Oct 27, 2024
  4. picnixz commented on Oct 27, 2024

    @picnixz
    Author
  5. added
    3.12only security fixes
    3.13only security fixes
    3.14bugs and security fixes
    on Oct 27, 2024
  6. ZeroIntensity commented on Oct 27, 2024

    @ZeroIntensity
    Member

    My main concern here is that while we can fix this as much as we want for the core, this looks like it's common enough that downstream is having this problem too.

  7. sobolevn commented on Oct 28, 2024

    @sobolevn
    Member

    Basically, we need to protect base from mutation during the iteration over it. An extra field maybe?

  8. picnixz commented on Oct 28, 2024

    @picnixz
    MemberAuthor

    See #126041 for that (the issue and PR may have passed under your radar :))

  9. changed the title [-]Crash: `xml.etree.ElementTree.Element.remove` with an evil `Element.__eq__`[/-] [+]Crash: `xml.etree.ElementTree.Element.remove` when concurrent mutations happen[/+] on Dec 17, 2024
  10. changed the title [-]Crash: `xml.etree.ElementTree.Element.remove` when concurrent mutations happen[/-] [+]UAF: `xml.etree.ElementTree.Element.remove` when concurrent mutations happen[/+] on Mar 31, 2025
  11. added a commit that references this issue on Mar 31, 2025
  12. added 2 commits that reference this issue on Mar 31, 2025
  13. added 2 commits that reference this issue on Mar 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.12only security fixes3.13only security fixes3.14bugs and security fixesextension-modulesC modules in the Modules dirtopic-XMLtype-crashA hard crash of the interpreter, possibly with a core dump

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions