Directly constructed subprocess pipe protocols segfault when callbacks use a non-process owner
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- backend, operating-systems
Research direction
Start by reproducing the three constructor-and-callback cases for ReadSubprocessPipeProto and WriteSubprocessPipeProto, then inspect their generated callbacks in uvloop/loop.c at the reported locations. Use the ASan/UBSan findings to trace invalid owner access, and verify that each case raises a Python exception instead of terminating the interpreter.
Written by the indexing model from the issue text.
Description
Summary
ReadSubprocessPipeProto and WriteSubprocessPipeProto accept ordinary integers as constructor arguments, after which the listed protocol callbacks terminate the interpreter.
I realize this is not a realistic input or usage pattern, but I would expect a Python exception rather than a process crash.
Versions
uvloop 0.22.1, CPython 3.12.3, Debian 12 x86_64, glibc 2.36
Reproducer
Each call below reproduces independently in a fresh process.
from uvloop.loop import ReadSubprocessPipeProto, WriteSubprocessPipeProto
ReadSubprocessPipeProto(1, 7).data_received(b"data")
WriteSubprocessPipeProto(1, 7).connection_lost(None)
WriteSubprocessPipeProto(1, 7).resume_writing()
Segmentation fault (core dumped)
ASan/UBSan result
I built uvloop 0.22.1 from source with Clang 18 using ASan and UBSan instrumentation.
ASan reports zero-page reads for data_received() and connection_lost() in their generated Cython callbacks:
ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000e0
The signal is caused by a READ memory access.
#0 ReadSubprocessPipeProto.data_received
uvloop/loop.c:130047:177
SUMMARY: AddressSanitizer: SEGV
uvloop/loop.c:130047:177
The connection_lost() variant reports an equivalent read from address 0xd8 at uvloop/loop.c:129583.
For resume_writing(), UBSan first reports misaligned PyObject access in Py_INCREF at uvloop/loop.c:129886, and ASan then reports the resulting read fault.
The sanitizer processes exit with code 134 after ASan aborts.
I found this while fuzzing Python C extension modules.
- Dominant language
- Cython
- Stars
- 11.9k
- Forks
- 615
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
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.
More from MagicStack/uvloop
-
License not clear Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
MagicStack/uvloop#759 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
MagicStack/uvloop#741 · 2 reactions ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
MagicStack/uvloop#702 · 8 comments · 9 reactions ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
MagicStack/uvloop#766 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
MagicStack/uvloop#763 ·
All issues in MagicStack/uvloop
Similar issues
-
bug customer-eng Durable Agents Inngest status: needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
integration: elevenlabs
Difficulty 1/5 Under an hour Newbie friendliness 88/100
home-assistant/core#182944 · 1 comment ·
-
ai-observability bug team/ai-observability
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
vicharanashala/fln#563 ·