Skip to content

getargs.c is Breaking Interpeter Isolation #119213

Activity

  1. ericsnowcurrently commented on May 21, 2024

    @ericsnowcurrently
    MemberAuthor

    Here's what I've found:

    • there's a bug (in 3.13/main) where _PyRuntime.getargs.static_parsers is only ever set to the last node added by _parser_init()
    • for non-builtin modules (even for Py_BUILD_CORE_MODULE) _PyArg_Parser.kwtuple is allocated on the heap under the current interpreter

    The first bug masks the problem on 3.13/main, so thankfully @1st1 was testing on 3.12.

    The second bug is solvable by either always statically allocating the kwtuple or by always temporarily switching to the main interpreter when allocating from the heap.

    Now that I can reliably reproduce the crash I'll have a fix up soon.

  2. ericsnowcurrently commented on May 21, 2024

    @ericsnowcurrently
    MemberAuthor

    One other note:

    If I destroy the interpreter before runtime finalization I hit an assertion about negative refcount:

    ./Include/object.h:1040: _Py_NegativeRefcount: Assertion failed: object has negative ref count
    <object at 0x7f6922fd5800 is freed>
    Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
    Python runtime state: finalizing (tstate=0x000055d542ee5cb0)
    
    Current thread 0x00007f692773b100 (most recent call first):
      <no Python frame>
    Aborted (core dumped)
    

    If I do not destroy the subinterpreter before runtime fini then it crashes due to the dangling pointer:

    Debug memory block at address p=0x7f06a7ad4620: API ''
        71492436437630461 bytes originally requested
        The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfd):
            at p-7: 0x00 *** OUCH
            at p-6: 0x00 *** OUCH
            at p-5: 0x00 *** OUCH
            at p-4: 0x00 *** OUCH
            at p-3: 0x00 *** OUCH
            at p-2: 0x00 *** OUCH
            at p-1: 0x00 *** OUCH
        Because memory is corrupted at the start, the count of bytes requested
           may be bogus, and checking the trailing pad bytes may segfault.
        The 8 pad bytes at tail=0xfe7d04a5ab441d are Segmentation fault (core dumped)
    
  3. added a commit that references this issue on May 22, 2024
  4. added a commit that references this issue on May 22, 2024
  5. added 2 commits that reference this issue on May 22, 2024
  6. ericsnowcurrently commented on May 22, 2024

    @ericsnowcurrently
    MemberAuthor

    FTR, original change: gh-95860

  7. added a commit that references this issue on May 22, 2024
  8. ericsnowcurrently commented on May 23, 2024

    @ericsnowcurrently
    MemberAuthor

    Thanks for identifying the bug here, @1st1. Let me know if you notice any problems with the fix.

  9. added a commit that references this issue on Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.12only security fixes3.13only security fixes3.14bugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)topic-subinterpreterstype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions