heap-buffer-overflow in pycore_interpframe.h _PyFrame_Initialize

[YuanchengJiang]

Crash report

What happened?

import sys
import asyncio

class JumpTracer:
    def __init__(self, func, jump_to):
        self.code = func.__code__
        self.jump_to = jump_to
        self.first_line = None

    def trace(self, frame, event, arg):
        if self.first_line is None and event == 'line' and frame.f_code is self.code:
            self.first_line = frame.f_lineno - 1
            try:
                frame.f_lineno = self.first_line - self.jump_to
            except TypeError:
                frame.f_lineno = self.jump_to
        return self.trace

async def target():
    # Keep a couple of lines so the tracer has places to land.
    x = 0
    x += 1
    return x

if __name__ == "__main__":
    tracer = JumpTracer(target, jump_to=1)
    sys.settrace(tracer.trace)
    asyncio.run(target())

=================================================================
==1675806==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x510000044e00 at pc 0x61c306b4803a bp 0x7ffebaccfa40 sp 0x7ffebaccfa30
WRITE of size 8 at 0x510000044e00 thread T0
    #0 0x61c306b48039 in _PyFrame_Initialize ../Include/internal/pycore_interpframe.h:154
    #1 0x61c306b48039 in _PyEvalFramePushAndInit ../Python/ceval.c:1874
    #2 0x61c306b5262f in _PyEval_Vector ../Python/ceval.c:1995
    #3 0x61c3067d3af3 in _PyObject_VectorcallTstate ../Include/internal/pycore_call.h:169
    #4 0x61c3067d3af3 in PyObject_VectorcallMethod ../Objects/call.c:859
    #5 0x61c306d8d296 in call_soon ../Modules/_asynciomodule.c:388
    #6 0x61c306d97254 in future_schedule_callbacks ../Modules/_asynciomodule.c:455
    #7 0x61c306d9bf0a in future_set_result ../Modules/_asynciomodule.c:653
    #8 0x61c306d9bf0a in task_step_impl ../Modules/_asynciomodule.c:3147
    #9 0x61c306da0377 in task_step ../Modules/_asynciomodule.c:3463
    #10 0x61c306da0377 in TaskStepMethWrapper_call ../Modules/_asynciomodule.c:2120
    #11 0x61c3067cfc5d in _PyObject_MakeTpCall ../Objects/call.c:242
    #12 0x61c306b98e24 in _PyObject_VectorcallTstate ../Include/internal/pycore_call.h:167
    #13 0x61c306b98e24 in context_run ../Python/context.c:728
    #14 0x61c3067d678e in _PyVectorcall_Call ../Objects/call.c:273
    #15 0x61c3067d678e in _PyObject_Call ../Objects/call.c:348
    #16 0x61c3067d678e in PyObject_Call ../Objects/call.c:373
    #17 0x61c306675e9c in _PyEval_EvalFrameDefault ../Python/generated_cases.c.h:2616
    #18 0x61c306b51fb6 in _PyEval_EvalFrame ../Include/internal/pycore_ceval.h:121
    #19 0x61c306b51fb6 in _PyEval_Vector ../Python/ceval.c:2005
    #20 0x61c306b51fb6 in PyEval_EvalCode ../Python/ceval.c:888
    #21 0x61c306d103fe in run_eval_code_obj ../Python/pythonrun.c:1365
    #22 0x61c306d103fe in run_mod ../Python/pythonrun.c:1459
    #23 0x61c306d150a7 in pyrun_file ../Python/pythonrun.c:1293
    #24 0x61c306d150a7 in _PyRun_SimpleFileObject ../Python/pythonrun.c:521
    #25 0x61c306d15bcc in _PyRun_AnyFileObject ../Python/pythonrun.c:81
    #26 0x61c306d883cc in pymain_run_file_obj ../Modules/main.c:410
    #27 0x61c306d883cc in pymain_run_file ../Modules/main.c:429
    #28 0x61c306d883cc in pymain_run_python ../Modules/main.c:691
    #29 0x61c306d89cae in Py_RunMain ../Modules/main.c:772
    #30 0x61c306d89cae in pymain_main ../Modules/main.c:802
    #31 0x61c306d89cae in Py_BytesMain ../Modules/main.c:826
    #32 0x7ee30b1ea1c9  (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 282c2c16e7b6600b0b22ea0c99010d2795752b5f)
    #33 0x7ee30b1ea28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 282c2c16e7b6600b0b22ea0c99010d2795752b5f)

0x510000044e00 is located 0 bytes after 192-byte region [0x510000044d40,0x510000044e00)
allocated by thread T0 here:
    #0 0x7ee30b5b89c7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x61c306be8c1e in _PyObject_MallocWithType ../Include/internal/pycore_object_alloc.h:46
    #2 0x61c306be8c1e in gc_alloc ../Python/gc.c:2343
    #3 0x61c306be8c1e in _PyObject_GC_NewVar ../Python/gc.c:2385
    #4 0x61c306822e1c in make_gen ../Objects/genobject.c:927
    #5 0x61c30682d932 in _Py_MakeCoro ../Objects/genobject.c:970
    #6 0x61c30667b85d in _PyEval_EvalFrameDefault ../Python/generated_cases.c.h:10356
    #7 0x61c306b51fb6 in _PyEval_EvalFrame ../Include/internal/pycore_ceval.h:121
    #8 0x61c306b51fb6 in _PyEval_Vector ../Python/ceval.c:2005
    #9 0x61c306b51fb6 in PyEval_EvalCode ../Python/ceval.c:888
    #10 0x61c306d103fe in run_eval_code_obj ../Python/pythonrun.c:1365
    #11 0x61c306d103fe in run_mod ../Python/pythonrun.c:1459
    #12 0x61c306d150a7 in pyrun_file ../Python/pythonrun.c:1293
    #13 0x61c306d150a7 in _PyRun_SimpleFileObject ../Python/pythonrun.c:521
    #14 0x61c306d15bcc in _PyRun_AnyFileObject ../Python/pythonrun.c:81
    #15 0x61c306d883cc in pymain_run_file_obj ../Modules/main.c:410
    #16 0x61c306d883cc in pymain_run_file ../Modules/main.c:429
    #17 0x61c306d883cc in pymain_run_python ../Modules/main.c:691
    #18 0x61c306d89cae in Py_RunMain ../Modules/main.c:772
    #19 0x61c306d89cae in pymain_main ../Modules/main.c:802
    #20 0x61c306d89cae in Py_BytesMain ../Modules/main.c:826
    #21 0x7ee30b1ea1c9  (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 282c2c16e7b6600b0b22ea0c99010d2795752b5f)
    #22 0x7ee30b1ea28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 282c2c16e7b6600b0b22ea0c99010d2795752b5f)

SUMMARY: AddressSanitizer: heap-buffer-overflow ../Include/internal/pycore_interpframe.h:154 in _PyFrame_Initialize
Shadow bytes around the buggy address:
  0x510000044b80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x510000044c00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x510000044c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05
  0x510000044d00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x510000044d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x510000044e00:[fa]fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x510000044e80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x510000044f00: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x510000044f80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
  0x510000045000: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x510000045080: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==1675806==ABORTING

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

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

No response

[picnixz]

@gaogaotiantian Is this a legitimate use of sys.settrace? In the legacy tracing, the line event resetted the frame linenumber after the handler was called but not with the new system. Was it intended?

[gaogaotiantian]

We should not have a heap-buffer-overflow even if the user uses weird tracing functions. jump is a hell hole but as long as we support it, we should make the best effort to make it stable. It seems like you already found the culprit? I don't have any idea looking at the repro code directly. If you can point out the issue maybe I'll understand why this happens better.

[efimov-mikhail]

Sorry, misclick.

[picnixz]

It seems like you already found the culprit?

I am not entirely sure it is the culprit as I didn't check more in detail. I will check this w-e whether it is the case or not but this is one difference between the new and old tracing. I thiught it could be related as the custom trace modifies the frame.

[picnixz]

Something about the line is wrong. When I run the script, the line I jump to is line 20 which is async def target. If I change it to a regular function, it doesn't crash anymore. I don't really know if asyncio could be responsible for that as well.

[picnixz]

@kumaraditya303 Do you think it could be an asyncio issue here as we're messing with the frame lineno?

[kumaraditya303]

It is not related to asyncio, I am able to reproduce this without asyncio by running the coroutine directly as well:

import sys

class JumpTracer:
    def __init__(self, func, jump_to):
        self.code = func.__code__
        self.jump_to = jump_to
        self.first_line = None

    def trace(self, frame, event, arg):
        if self.first_line is None and event == 'line' and frame.f_code is self.code:
            self.first_line = frame.f_lineno - 1
            try:
                frame.f_lineno = self.first_line - self.jump_to
            except TypeError:
                frame.f_lineno = self.jump_to
        return self.trace

async def target():
    # Keep a couple of lines so the tracer has places to land.
    x = 0
    x += 1
    return x

if __name__ == "__main__":
    tracer = JumpTracer(target, jump_to=1)
    sys.settrace(tracer.trace)
    try:
        target().send(None)
    except StopIteration:
        pass

Output:

❯ ./python.exe main.py
/Users/kumaraditya/work/cpython/main.py:13: RuntimeWarning: assigning None to 1 unbound local
  frame.f_lineno = self.first_line - self.jump_to
Assertion failed: (frame->frame_obj == NULL), function _PyEval_EvalFrameDefault, file generated_cases.c.h, line 10366.
fish: Job 1, './python.exe main.py' terminated by signal SIGABRT (Abort)

[sergey-miryanov]

Little bit simpler (based on @kumaraditya303 comment), without async:

import sys

class JumpTracer:
    def __init__(self, func):
        self.code = func.__code__

    def trace(self, frame, event, arg):
        if event == 'line' and frame.f_code is self.code:
            frame.f_lineno = frame.f_lineno - 1
        return self.trace

def target():
    yield

if __name__ == "__main__":
    tracer = JumpTracer(target)
    sys.settrace(tracer.trace)
    t = target()
    next(t)

Anyone working on this?

[gaogaotiantian]

I’ll take a look in a few days if no one volunteers. This is probably related to how we deal with jumps, which is a huge hole.

[Abhi210]

May I give this a try? (I am not sure if I will be able to resolve the issue, but I can attempt it.)

[Abhi210]

I attempted to debug this issue using GDB to understand where the problem might be occurring. Based on the author's code snippet:

 			self.first_line = frame.f_lineno - 1
            print(self.first_line)
            try:
                frame.f_lineno = self.first_line - self.jump_to
            except TypeError:
                frame.f_lineno = self.jump_to

The tracer attempts to return to the previous bytecode instruction^? and then jumps to the specified jump line. This setting of jump occurs in the frameobject.c in the following function:

static int
frame_lineno_set_impl(PyFrameObject *self, PyObject *value)

Now, running a gdb with a break at this function revealed the following:

Breakpoint 1, frame_lineno_set_impl (self=0x51100006a5a0, value=0x5555564d62f8 <_PyRuntime+30872>) at Objects/frameobject.c:1656
1656	{
(gdb) n
1657	   PyCodeObject *code = _PyFrame_GetCode(self->f_frame);
...
1724	   long l_new_lineno = PyLong_AsLongAndOverflow(value, &overflow);
1725	   if (overflow
(gdb) p l_new_lineno
$1 = 21
...
1737	   if (new_lineno < code->co_firstlineno) {
(gdb) p code->co_firstlineno
$3 = 21

We see that co_firstlineno=21 in this case, and also new_lineno=21. I suspect that the culprit then should be the following check:

 if (new_lineno < code->co_firstlineno) {
        PyErr_Format(PyExc_ValueError,
                    "line %d comes before the current code block",
                    new_lineno);
        return -1;
    }

The user's code subtracted one from the first line as self.first_line = frame.f_lineno - 1. That is, the new_lineno should be less than co_firstlinen . GDB shows that they are both equal, indicating that it jumped on the first line itself. Hence, it should raise ValueError in this case. Instead, it skips over the above error and proceeds further. This could be the reason for frame->frame_obj == NULL.

Therefore, a recommended fix should be:

-  if (new_lineno < code->co_firstlineno) {
+  if (new_lineno <= code->co_firstlineno) {

Applying the above fix and running the author's code gave me the following error:

Traceback (most recent call last):
  File "/home/abhishek/Python/filescpy/test_140802_2.py", line 19, in <module>
    next(t)
    ~~~~^^^
  File "/home/abhishek/Python/filescpy/test_140802_2.py", line 13, in target
    yield
  File "/home/abhishek/Python/filescpy/test_140802_2.py", line 9, in trace
    frame.f_lineno = frame.f_lineno - 1
    ^^^^^^^^^^^^^^
ValueError: line 21 comes before the current code block

^? PS: I have recently started learning about CPython internals. Therefore, the terminology I used may be incorrect in this context. I'm so sorry about this!
PPS: Sorry if this was some bad analysis! Also, I am utilizing LLMs to assist me in debugging the issues. I am unsure whether it violates these community rules.