@dpdani Thanks for you review!

Independent confirmation of item (69) "Unsynchronized extra pointer dereference in len in Modules/_elementtree.c", found by ThreadSanitizer fuzzing (fusil --tsan). Worth noting the race is a bit broader than a read-deref: it's a write/write on the lazily-allocated self->extra, because the if (!self->extra) create_extra(...) guard in the extra accessors isn't atomic. Two threads first-touching a shared Element both take the !self->extra branch and both run create_extra, which does self->extra = PyMem_Malloc(...) (_elementtree.c:274) with no critical section — so one allocation is overwritten (leaked) and readers can observe a torn pointer.

Minimal deterministic reproducer (exit 66 under TSan; create_extra:274 as the write, reached via element_attrib_getter / element_length):

import threading
import xml.etree.ElementTree as ET

NTHREADS = 8
barrier = threading.Barrier(NTHREADS)

def worker(elem):
    barrier.wait()
    for _ in range(4000):
        _ = elem.attrib          # if (!self->extra) create_extra(...) -- unlocked lazy init
        _ = len(elem)            # element_length reads self->extra

for _ in range(200):
    shared = ET.Element("tag")   # extra == NULL until first attrib/child touch
    ts = [threading.Thread(target=worker, args=(shared,)) for _ in range(NTHREADS)]
    for t in ts: t.start()
    for t in ts: t.join()

Confirmed still present on current main (3.16.0a0), on both a debug and a release --with-thread-sanitizer build. PR #149918's approach — taking Py_BEGIN_CRITICAL_SECTION(self) around the if (!self->extra) create_extra(...) check-and-create and the other extra accessors — covers this (both the read-deref and the write/write faces). Faces the fuzzer also hit: create_extra | element_length and clear_extra | create_extra.

(Found by fusil --tsan, a ThreadSanitizer fuzzer; draft and reproducer by Claude Code, minimized and reviewed by hand.)