[New-bugs-announce] [issue44240] Incorrect behavior of LOAD_ATTR due to overflow in tp_version
report at bugs.python.org
Wed May 26 12:03:18 EDT 2021
New submission from Mark Shannon <mark at hotpy.org>:
Should the tp_version overflow, and wrap around to a value previously used in the opcache for LOAD_ATTR, then LOAD_ATTR could produce the wrong value.
It will take a fair bit of contrivance and a long time to do this, but it is possible:
Run some code ~2000 times to get the version cached.
Change an attibute of the type about 4 billion times.
Rerun the original code.
Invalidating all the opcaches is going to be a huge pain, so I propose not allowing the version to overflow but partitioning the 32 bit space something like this:
Top 20 bits: Unique per-class ID, 0 and 0xFFFFF are reserved.
Low 12 bits: Per-class version.
tp_version == 0 that no version has been assigned to this class, as yet.
(tp_version & 0xFFF) == 0 means that the version tag is temporarily invalid
tp_version == 0xFFFFFFFF means that the version tag is permanently invalid
If (tp_version & 0xFFF) != 0 and tp_version != 0xFFFFFFFF, then the combined 32 bits represents a unique tag of the class's state as it does now.
Should the low bits of a class hit 0xFFF then all 32 bits are set to 0xFFFFFFFF, and we can't cache its version any more.
If a class has been changed a 1000 times, then there is unlikely to be much value in caching it anyway.
components: Interpreter Core
nosy: Mark.Shannon, pablogsal
stage: needs patch
title: Incorrect behavior of LOAD_ATTR due to overflow in tp_version
versions: Python 3.10, Python 3.9
Python tracker <report at bugs.python.org>
More information about the New-bugs-announce