Fix: memory corruption from nested internal function calls #2345
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.
What I did
Fix a runtime bug allowing for memory corruption when making an internal function call inside a literal array or another function call.
The issue is the same as the one outlined in GHSA-2r3x-4mrv-mcxf and fixed in #2186. In my previous fix I did not fully comprehend the scope of the issue, and so the bug was still present when making a private function call inside a literal array, or when accessing a single indexed value from a private function call returning a list or tuple.
How I did it
Expand the logic added in #2186, applying it also to
Subscript
andList
nodes. I have refactored the check into it's own new function,parse_sequence
, which is applied on all lists, tuples, and private function calls. There is some recursive logic to account for multidimensional arrays.How to verify it
Run the tests. I've included some new cases - awful code that nobody should ever write, that would cause the bug to appear in very many varieties (if it were still around).
Cute Animal Picture