You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix cases of incorrect allocator or deallocator inheritance - #6559
This PR fixes two cases of incorrect inheritance of tp_alloc or tp_free causing crashes with various #[pyclass] types:
We weren't previously explicitly setting the allocator, except for #[pyclass(freelist)] and invalid base allocators might not allocate space for the Rust data (this happens to be the case for datetime.time, for example). This could be viewed as a bug in the base allocator but I think it doesn't hurt for us to be defensive and select PyType_GenericAlloc explicitly (this is the documented behaviour for heap types but not what happens in practice, see also documentation of tp_alloc and tp_free inheritance for heap types is incorrect python/cpython#160749).
For #[pyclass(freelist)] struct Base, an inherited #[pyclass] struct Child would accidentally inherit Base deallocator and corrupt the base freelist with a Child object.
Whilst fixing these cases I decided to make TP_ALLOC and TP_FREE constants inside the PyClassImpl trait, which allows for the most concise generated code while setting the defaults & allowing the freelist override.
Although both are nasty crashes, I think they would be discovered during development so not CVE-worthy.
Merging this PR will degrade performance by 17.55%
1 warning
⚠️Base and head ran on different runner types
Some benchmarks with significant performance changes were compared across different runner types, so the changes might not come from the code. Run base and head on the same runner type, or use CodSpeed Macro Runners for more stable results.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes two cases of incorrect inheritance of
tp_allocortp_freecausing crashes with various#[pyclass]types:We weren't previously explicitly setting the allocator, except for
#[pyclass(freelist)]and invalid base allocators might not allocate space for the Rust data (this happens to be the case fordatetime.time, for example). This could be viewed as a bug in the base allocator but I think it doesn't hurt for us to be defensive and selectPyType_GenericAllocexplicitly (this is the documented behaviour for heap types but not what happens in practice, see also documentation oftp_allocandtp_freeinheritance for heap types is incorrect python/cpython#160749).For
#[pyclass(freelist)] struct Base, an inherited#[pyclass] struct Childwould accidentally inheritBasedeallocator and corrupt the base freelist with aChildobject.Whilst fixing these cases I decided to make
TP_ALLOCandTP_FREEconstants inside thePyClassImpltrait, which allows for the most concise generated code while setting the defaults & allowing the freelist override.Although both are nasty crashes, I think they would be discovered during development so not CVE-worthy.
Bug discovery credit OpenAI (OutboundDisclosures@openai.com)