`sentinel()` construction races `func.__module__` reassignment in `caller()` under free-threading

[devdanzin]

Crash report

What happened?

On a free-threaded build, constructing a PEP 661 sentinel() in one thread while another thread reassigns the enclosing function's __module__ causes a heap use-after-free and SIGSEGV.

Objects/sentinelobject.c's caller() reads func->func_module as a borrowed reference and then Py_NewRefs it, with no protection against a concurrent reassignment freeing that module in the window between the read and the incref. The freed pointer is baked into the new sentinel's self->module; when the sentinel is later collected, sentinel_clear's Py_CLEAR(self->module) decrefs the dangling pointer and _Py_Dealloc reads a freed type slot → crash.

Reproducer

import sys, threading, time

class M:
 __slots__ = ("payload",)
 def __init__(self):
 self.payload = bytearray(128)

def make():
 return sentinel("X") # sentinel() -> caller() reads make.__module__

make.__module__ = M()
stop = False

def churn(): # reassign make.__module__ rapidly
 while not stop:
 make.__module__ = M()

def build(): # construct + drop sentinels
 while not stop:
 s = make(); del s

ts = [threading.Thread(target=churn) for _ in range(4)]
ts += [threading.Thread(target=build) for _ in range(8)]
for t in ts: t.start()
time.sleep(5); stop = True
for t in ts: t.join()
print("survived (no crash this run)")

Crashes reliably, only on a free-threaded build.

Root cause

Objects/sentinelobject.c, caller() (≈ lines 41–46):

PyFunctionObject *func = _PyFrame_GetFunction(f);
assert(PyFunction_Check(func));
PyObject *r = PyFunction_GetModule((PyObject *)func); /* BORROWED reference */
if (!r) {
 assert(!PyErr_Occurred());
 Py_RETURN_NONE;
}
return Py_NewRef(r); /* increfs the borrowed ref */

PyFunction_GetModule returns a borrowed reference to func->func_module. Between that read and Py_NewRef(r), a concurrent func.__module__ = ... can drop the previous module object's last reference to 0 and free it; Py_NewRef(r) then operates on freed memory.

The result is stored into the sentinel by sentinel_new_impl → sentinel_new_with_module (≈ line 59):

self->module = Py_NewRef(module); /* dangling pointer baked into the sentinel */

and later released by sentinel_clear (line 129):

Py_CLEAR(self->module); /* Py_DECREF on the dangling pointer -> UAF */

Backtrace

Debug free-threaded build, faulting thread:

#0 _Py_Dealloc (op=<freed module>) at ./Include/internal/pycore_pystate.h:339
#1 Py_DECREF (op=<freed module>) at ./Include/refcount.h:363
#2 sentinel_clear (op=<sentinel>) at Objects/sentinelobject.c:129
#3 sentinel_dealloc (op=<freed module>) at Objects/sentinelobject.c:138

Release free-threaded build (same repro), faulting thread lands one step later, in the allocator freeing the corrupted object:

#0 mi_free at Objects/mimalloc/alloc.c:576
#1 _PyObject_MiFree at Objects/obmalloc.c:381
#2 subtype_dealloc at Objects/typeobject.c:2876
#3 _Py_Dealloc at Objects/object.c:3319

Related

Same borrowed-reference-under-free-threading class as #153297 ("double-decref in func_set_qualname under free-threading") and the broader funcobject.c getset FT-unsafety. The shared root is that func->func_module (and the other function fields) can be reassigned concurrently, so any consumer that reads them borrowed and then increfs is racy on the free-threaded build. Here the unsafe consumer is caller() in sentinelobject.c rather than a funcobject.c getset.

---

Found, investigated, and drafted with assistance from Claude Code (Opus 4.8).

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

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

Python 3.16.0a0 free-threading build (heads/main:bcf98ddbc40, Jul 4 2026, 15:09:31) [Clang 21.1.8 (6ubuntu1)]

Linked PRs

• gh-153531: fix thread safety of setting func.__doc__ and func.__module__ #154851
• [3.15] gh-153531: fix thread safety of setting func.__doc__ and func.__module__ (GH-154851) #154856
• [3.14] gh-153531: fix thread safety of setting func.__doc__ and func.__module__ (GH-154851) #154857

[sobolevn]

Thanks for the report, I have a fix ready :)

[sobolevn]

We need #153335 to get merged before my fix for this issue can be merged :)

[devdanzin]

Thanks @sobolevn! While confirming this, I found the same borrowed-PyFunction_GetModule pattern in a second copy of caller(): Objects/typevarobject.c has its own near-identical caller() that feeds TypeVar / ParamSpec / TypeVarTuple / TypeAliasType construction:

/* Objects/typevarobject.c, caller() ~line 400 */
PyObject *r = PyFunction_GetModule(PyStackRef_AsPyObjectBorrow(f->f_funcobj)); /* borrowed */
if (!r) { PyErr_Clear(); Py_RETURN_NONE; }
return Py_NewRef(r); /* increfs borrowed ref */

The dangling module is stored as the new object's __module__ (into its managed dict), and it faults later in typevar_dealloc → PyObject_ClearManagedDict → clear_inline_values. Same race, reproducible the same way (SIGSEGV on the debug FT build, but clean under -X gil=1):

import sys, threading, time
from typing import TypeVar
class M:
 __slots__ = ("payload",)
 def __init__(self): self.payload = bytearray(128)
def make(): return TypeVar("X") # ParamSpec/TypeVarTuple/`type X = int` hit the same caller()
make.__module__ = M()
stop = False
def churn():
 while not stop: make.__module__ = M()
def build():
 while not stop:
 s = make(); del s
ts = [threading.Thread(target=churn) for _ in range(4)]
ts += [threading.Thread(target=build) for _ in range(8)]
for t in ts: t.start()
time.sleep(5); stop = True
for t in ts: t.join()

There's also a sibling in the same file — the TypeAliasType.__module__ getter (~line 1975) does the same unprotected Py_NewRef on a borrowed PyFunction_GetModule(ta->compute_value) result (it even has a comment noting the borrowed reference), just after a Py_END_CRITICAL_SECTION().

Does your pending fix here also cover the typevarobject.c caller() copy and that getter, or would you like a separate issue for them? Happy to file one if it's cleaner to track separately.

Backtraces and per-build details available if useful. Investigation and draft by Claude Code (Opus 4.8).

[sobolevn]

Does your pending fix here also cover the typevarobject.c caller() copy and that getter, or would you like a separate issue for them?

Yeah :)
I also found it while greping code.