Visitar URL original
create_builtin() in _imp module trigger segfault if taking a builtin object as input · Issue #98354 · python/cpython · GitHub
Skip to content

create_builtin() in _imp module trigger segfault if taking a builtin object as input #98354

Description

@xiaxinmeng

Crash report

In the following test program, _imp.create_builtin takes a object A as input. The object instance the name attribute as "self" at "self.name = self". This action triggers a segfault on CPython 3.10.7 and CPython 3.10.7. Similarly, if self.name = other keywords, e.g.,int, print, the program also crashes. It may need a checker for _imp.create_builtin to avoid keywords.

import _imp

class FakeSpec:
	def __init__(self, name):
		self.name = self

A = FakeSpec("time")

imp_time = _imp.create_builtin(A)

Error messages

Expected behavior on CPython 3.9.0

Traceback (most recent call last):
  File "/home/xxm/Desktop/imp.py", line 9, in <module>
    imp_time = _imp.create_builtin(A)
TypeError: bad argument type for built-in operation

Unexpected Behavior on CPython 3.10.8
Segmentation fault(core dumped)

Your environment

  • CPython versions tested on:Python 3.10.8, Python 3.10.7

  • Operating system and architecture: [GCC 7.5.0] on linux

Activity

  1. added
    type-crashA hard crash of the interpreter, possibly with a core dump
    on Oct 17, 2022
  2. chgnrdv commented on Oct 18, 2022

    @chgnrdv
    Contributor

    Crashes on 3.12.0a0 with the following message:

    Objects/unicodeobject.c:498: _PyUnicode_CheckConsistency: Assertion failed: PyType_HasFeature((Py_TYPE(((PyObject*)((op))))), ((1UL << 28)))
    Enable tracemalloc to get the memory block allocation traceback
    
    object address  : 0x7ffff77eb530
    object refcount : 4
    object type     : 0x555555c2b9b0
    object type name: FakeSpec
    object repr     : <__main__.FakeSpec object at 0x7ffff77eb530>
    
    Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
    Python runtime state: initialized
    
    Current thread 0x00007ffff7cad740 (most recent call first):
      File "/home/.../cpython/crash_98354.py", line 9 in <module>
    
    Program received signal SIGABRT, Aborted.
    

    Looks like _imp_create_builtin should check name for being a str instance in general, not only to avoid it being a keyword.

  3. ericsnowcurrently commented on Oct 19, 2022

    @ericsnowcurrently
    Member

    To be clear, code should not be using the _imp module directly. That said, this would be relatively easy to reproduce with a metapath finder.

    Regardless, I was able to reproduce this on main (3.12, c051d55) using the OP code. It is not crashing on 3.8 (but does fail with a TypeError). Likewise with 3.9.

    It does start crashing in 3.10. Looks like it started in 6223071 (GH-23378). It was probably caught before by the PyUnicode_AsUTF8() (which was removed). Checking for PyUnicode should restore the pre-3.10 behavior.

  4. added a commit that references this issue on Oct 20, 2022
  5. added a commit that references this issue on Oct 20, 2022
  6. ericsnowcurrently commented on Nov 2, 2022

    @ericsnowcurrently
    Member

    Per #98412 (comment), this might not be completely fixed yet.

    @xiaxinmeng, can you verify if the problem you had is fixed on the main branch (i.e. 3.12a1)?

  7. ericsnowcurrently commented on Nov 21, 2022

    @ericsnowcurrently
    Member
  8. xiaxinmeng commented on Nov 23, 2022

    @xiaxinmeng
    Author

    Per #98412 (comment), this might not be completely fixed yet.

    @xiaxinmeng, can you verify if the problem you had is fixed on the main branch (i.e. 3.12a1)?

    Sorry for being late @ericsnowcurrently . I think this problem has been fixed.
    It does not crash CPython any more, the behavior on the main branch 8f18ac0 is as follows:

    Traceback (most recent call last):
      File "/home/xxm/Downloads/cpython-main(2)/test.py", line 9, in <module>
        imp_time = _imp.create_builtin(A)
                   ^^^^^^^^^^^^^^^^^^^^^^
    TypeError: name must be string, not FakeSpec
    
  9. chgnrdv commented on Feb 12, 2023

    @chgnrdv
    Contributor

    @ericsnowcurrently, sorry for the slow response. Yes, I confirm that refleak issue is fixed by gh-99578, and therefore we can close this one.

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.10 (EOL)end of lifetype-crashA hard crash of the interpreter, possibly with a core dump

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions