GeezerVison is showing github.com — `signalmodule.c` in free-threaded Python · Issue #161235 · python/cpython
signalmodule.c in free-threaded Python #161235
DescriptionThis issue is intended to track discussion on signalmodule.c for free-treaded Python as a spin off issues from #116738 given it way create some wider discussion on the best approach. And also a const benefit analysis of any additional checks or required re-design.
An initial audit with TSAN/code review exposed some issues.
| Issue |
Where |
What goes wrong |
signal.getsignal use-after-free |
signal_getsignal_impl vs signal_signal_impl |
Reader loads a handler pointer it doesn't own; main thread swaps and frees it before the reader increfs |
wakeup.fd data race |
trip_signal vs set_wakeup_fd |
One plain int read and written by two threads with no ordering |
PyErr_SetInterruptEx borrowed read |
PyErr_SetInterruptEx |
Reads and compares a handler pointer that another thread may have freed |
However per #161221 (comment) and linked post https://iafisher.com/2026/08/sigprint any mechanism to improve safety "bolted on" would be very hard get right due to the interrupt mechanism that is able to run at any time.
Linked PRs
Activityjohng commented on Nov 3, 2026 ContributorAuthor More actions One approach I've looked at for getsignal UAF is using _PyObject_XDecRefDelayed on the old handler which is also atomically swapped and relying on QSBR. It does not fully solve PyErr_SetInterruptEx since it can be called from C, although this might be a gap with GIL python too.
swap_handler(int i, PyObject *func)
{
/* Store func with an atomic operation to ensure
that PyErr_SetInterrupt is async-signal-safe. */
PyObject *old = _Py_atomic_exchange_ptr(&Handlers[i].func,
Py_XNewRef(func));
PyObject *result = Py_XNewRef(old);
_PyObject_XDecRefDelayed(old);
return result;
}
ngoldbaum commented on Nov 4, 2026
although this might be a gap with GIL python too
It's OK to let issues that happen on the GIL-enabled build continue to be issues. Ideally whatever you'd come up with would compose nicely with a thread-safe overall design. ngoldbaum commented on Nov 4, 2026 btw for anyone thinking of opening a PR, @johng is actively working on a fix, let us know before opening a PR if you'd like to work on this otherwise a triager may close your PR. johng commented on Nov 4, 2026 ContributorAuthor More actions Have raised a draft PR to demonstrate the above proposal as a real implementation but happy to gather feedback for the above suggestion here before any code review.
The tests there demonstrate the lack of reference that is maintained the "old" handlers which is the root cause of the TSAN failures for 1 and 3. A slightly less deterministic test with threads would result in a crash but unsure on precedence for that style of test.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|