Skip to content

LOAD_ATTR_SLOT and STORE_ATTR_SLOT don't check the owner's type #99257

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
brandtbucher opened this issue Nov 8, 2022 · 0 comments
Closed

LOAD_ATTR_SLOT and STORE_ATTR_SLOT don't check the owner's type #99257

brandtbucher opened this issue Nov 8, 2022 · 0 comments
Assignees
Labels
3.11 only security fixes 3.12 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) release-blocker type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@brandtbucher
Copy link
Member

brandtbucher commented Nov 8, 2022

When specializing LOAD_ATTR_SLOT, we don't check whether the given member descriptor is valid for the type we got it from.

Here is a problematic example, where one class "borrows" a slot from another:

>>> class Class:
...     __slots__ = ("slot",)
... 
>>> class Sneaky:
...     borrowed = Class.slot
... 
>>> def f(o):
...     return o.borrowed
... 
>>> o = Sneaky()

The unspecialized code behaves correctly:

>>> f(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in f
TypeError: descriptor 'slot' for 'Class' objects doesn't apply to a 'Sneaky' object

However, the specialized code crashes, since it is accessing memory past the end of the object:

>>> f(o)
Segmentation fault

We can fix this by performing the same check that the member descriptor performs (PyObject_TypeCheck(obj, descr->d_type)) when specializing.

CC @markshannon

@brandtbucher brandtbucher added interpreter-core (Objects, Python, Grammar, and Parser dirs) release-blocker 3.11 only security fixes type-crash A hard crash of the interpreter, possibly with a core dump 3.12 only security fixes labels Nov 8, 2022
@brandtbucher brandtbucher self-assigned this Nov 8, 2022
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Nov 10, 2022
Repository owner moved this from Todo to Done in Release and Deferred blockers 🚫 Nov 10, 2022
brandtbucher added a commit that referenced this issue Nov 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.11 only security fixes 3.12 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) release-blocker type-crash A hard crash of the interpreter, possibly with a core dump
Projects
Development

No branches or pull requests

1 participant