Skip to content

Specialized STORE_SUBSCR_DICT allows silent mutation of frozendict after adaptive specialization #145122

Description

@abdoulrasheed

Bug report

Bug description:

Commit 3e2f5c1 broadened _GUARD_NOS_DICT from PyDict_CheckExact() to PyAnyDict_CheckExact() for read operations (BINARY_OP_SUBSCR_DICT, CONTAINS_OP_DICT). However, the same guard is also used by STORE_SUBSCR_DICT, which still calls _PyDict_SetItem_Take2() directly; bypassing frozendict's immutability checks entirely.

When a function containing d[key] = value is first specialized with dict, subsequent calls with frozendict pass the widened guard and mutate the frozendict at the C level. In debug builds this is an assertion crash; in release builds it's silent mutation with a stale cached hash.

def store(d, key, val):
    d[key] = val

# specialize
for i in range(100):
    store({}, 'k', i)

# now frozendict passes the widened guard and is mutated
fd = frozendict({'a': 1})
h_before = hash(fd)

store(fd, 'b', 2)  # should raise TypeError

print(fd)       # frozendict({'a': 1, 'b': 2}),    mutated
print(hash(fd) == h_before)  # True, stale hash

Before specialization, store(frozendict(...), 'b', 2) correctly raises TypeError: 'frozendict' object does not support item assignment.

After specialization, it silently mutates the frozendict and leaves the cached hash stale.

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Linked PRs

Activity

  1. brianschubert commented on Feb 22, 2026

    @brianschubert
    Contributor

    Possibly addressed by #145039? cc @corona10

  2. abdoulrasheed commented on Feb 22, 2026

    @abdoulrasheed
    ContributorAuthor

    Yes, #145039 addresses this exactly; same root cause (_GUARD_NOS_DICT broadened to accept frozendict but shared by the write path).

    Closing.

  3. corona10 commented on Feb 23, 2026

    @corona10
    Member

    I prefer to update the PR to link this issue so that people are aware it is currently under review.
    cc @Fidget-Spinner @markshannon @vstinner

  4. corona10 commented on Feb 23, 2026

    @corona10
    Member

    Just for the record, Mark originally reported this issue here:
    #144949 (comment)

  5. self-assigned this
    on Feb 23, 2026
  6. added a commit that references this issue on Feb 24, 2026
  7. added a commit that references this issue on Feb 28, 2026
  8. added a commit that references this issue on Apr 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.15bugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)release-blockertype-bugAn unexpected behavior, bug, or error

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions