Bug Description
In Modules/_remote_debugging/code_objects.c:435, there is a NULL pointer dereference vulnerability due to incorrect ordering of conditions in a compound || expression.
The Bug
// Line 435
if (ctx->tlbc_index == 0 || unwinder->debug_offsets.code_object.co_tlbc == 0 || unwinder == NULL) {
C short-circuit evaluation means unwinder->debug_offsets (position 2) is dereferenced BEFORE unwinder == NULL (position 3) is checked. The NULL check is dead code — it can never protect against a NULL unwinder because the crash happens first.
Context
The code already shows awareness that unwinder can be NULL:
- Line 359:
if (unwinder && ...) — proper NULL check exists elsewhere
- The NULL check at line 435 proves the developer intended it to be nullable
Affected Versions
- Python 3.13t+ (free-threading builds)
- Python 3.14t+ (free-threading builds)
- Only affects
Py_GIL_DISABLED builds
Suggested Fix
// Move NULL check before dereference:
if (ctx->tlbc_index == 0 || unwinder == NULL || unwinder->debug_offsets.code_object.co_tlbc == 0) {
Impact
- NULL pointer dereference → crash
- Currently latent (callers always pass non-NULL)
- But the NULL check proves the developer intended nullable → future code changes could make this exploitable
- Potential denial-of-service if triggered
Reporter
- GitHub: agent-zeroo / nezukoagent
Linked PRs
Bug Description
In
Modules/_remote_debugging/code_objects.c:435, there is a NULL pointer dereference vulnerability due to incorrect ordering of conditions in a compound||expression.The Bug
C short-circuit evaluation means
unwinder->debug_offsets(position 2) is dereferenced BEFOREunwinder == NULL(position 3) is checked. The NULL check is dead code — it can never protect against a NULLunwinderbecause the crash happens first.Context
The code already shows awareness that
unwindercan be NULL:if (unwinder && ...)— proper NULL check exists elsewhereAffected Versions
Py_GIL_DISABLEDbuildsSuggested Fix
Impact
Reporter
Linked PRs