Mutable heap PyStructSequence types can segfault after modifying n_fields
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 35.9k
- PR merge metrics
- PR metrics pending
Description
Crash report
What happened?
Several heap PyStructSequence types can be crashed from pure Python by modifying the writable n_fields attribute on the type and then constructing a new instance.
The issue reproduces with at least:
os.terminal_sizeos.stat_resulttime.struct_timeresource.struct_rusage
Minimal reproducer:
import os
os.terminal_size.n_fields = 100000
os.terminal_size((1, 2))
This consistently terminates the interpreter with:
Segmentation fault (core dumped)
The crash also reproduces for other mutable heap PyStructSequence types by assigning a large value to n_fields before construction.
The backtrace shows the crash occurring in structseq_new_impl():
#0 __strlen_avx2()
#1 PyUnicode_FromString()
#2 PyDict_GetItemStringRef()
#3 structseq_new_impl() at Objects/structseq.c:243
At the point of failure:
max_len = 100000
i = 2
n_unnamed_fields = 0
From inspecting Objects/structseq.c, structseq_new_impl() uses the type's n_fields value to determine how many member names to process. After modifying n_fields from Python, the constructor eventually reaches a NULL member name, leading to a crash through PyDict_GetItemStringRef() and PyUnicode_FromString().
During investigation I also verified that immutable builtin structseq types such as sys.version_info are not affected because their type attributes cannot be modified and new instances cannot be created.
I searched the existing issue tracker using keywords including:
structseq_new_implPyStructSequence_NewTypen_fieldsObjects/structseq.cPyDict_GetItemStringReftp_members
but could not find an existing report describing this behavior.
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 (heads/main:e469fa9c807, Aug 7 2026, 09:37:12) [GCC 13.3.0]
Linked PRs
- gh-155361
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with Objects/structseq.c and structseq_new_impl(), then run the minimal os.terminal_size reproducer described in the issue. Compare the handling of the writable n_fields value with the available member names; done means constructing the affected types no longer crashes and regression coverage demonstrates the behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100