Skip to content
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

fix: uninitialized immutable values #3409

Merged

Conversation

charles-cooper
Copy link
Member

@charles-cooper charles-cooper commented May 14, 2023

What I did

fix #3101

How I did it

ensure msize is initialized past end of immutables section before entering the constructor.

How to verify it

the provided test cases fail on master (97ff017) but not on this branch.

Commit message

immutable variables can be read before assignment in constructor code,
and their memory location is accessed, but that memory might not yet
be initialized. prior to this commit, its value is not necessarily
`empty(type)` since memory could have been written to ephemerally. in
particular, `create_copy_of` (and its sister, `create_from_blueprint`)
use `msize` to determine a starting location for where to copy the
target bytecode into memory, while the immutables section start is
determined using the static memory allocator. in case that `msize` is
still less than the immutables section end, `create_copy_of` can write
to the immutables section, thereby resulting in reads from the
immutables section to return garbage.

this commit fixes the issue by issuing an `iload
<immutables_section_end> - 32` before executing any initcode, which
forces `msize` to be initialized past the end of the immutables section
(and therefore, accessing an immutable before it is initialized in the
constructor will produce the "expected" `empty()` value for the
immutable).

note that a corresponding `mload` is not required for runtime code,
because vyper requires all memory variables to be instantiated at the
declaration site, so there is no way that msize can produce a pointer to
an uninitialized memory variable.

Description for the changelog

Cute Animal Picture

Put a link to a cute animal picture inside the parenthesis-->

immutable variables can be read before assignment in constructor code,
and their memory location is accessed, but that memory might not yet
be initialized. prior to this commit, its value is not necessarily
`empty(type)` since memory could have been written to ephemerally. in
particular, `create_copy_of` (and its sister, `create_from_blueprint`)
use `msize` to determine a starting location for where to copy the
target bytecode into memory, while the immutables section start is
determined using the static memory allocator. in case that `msize` is
still less than the immutables section end, `create_copy_of` can write
to the immutables section, thereby resulting in reads from the
immutables section to return garbage.

this commit fixes the issue by issuing an `mload
<immutables_section_end>` before executing any initcode, which forces
`msize` to be initialized past the end of the immutables section (and
therefore, accessing an immutable before it is initialized in the
constructor will produce the "expected" `empty()` value for the
immutable).

note that a corresponding `mload` is not required for runtime code,
because vyper requires all memory variables to be instantiated at the
declaration site, so there is no way that msize can produce a pointer to
an uninitialized memory variable.
@charles-cooper charles-cooper requested a review from fubuloubu May 14, 2023 19:03
@charles-cooper charles-cooper changed the title fix: immutables read before assignment fix: uninitialized immutable values May 14, 2023
@codecov-commenter
Copy link

codecov-commenter commented May 14, 2023

Codecov Report

Merging #3409 (6a67eed) into master (4f9f813) will increase coverage by 0.08%.
The diff coverage is 100.00%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##           master    #3409      +/-   ##
==========================================
+ Coverage   89.09%   89.17%   +0.08%     
==========================================
  Files          84       84              
  Lines       10763    10765       +2     
  Branches     2452     2453       +1     
==========================================
+ Hits         9589     9600      +11     
+ Misses        781      771      -10     
- Partials      393      394       +1     
Impacted Files Coverage Δ
vyper/codegen/module.py 97.61% <100.00%> (+0.05%) ⬆️

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@charles-cooper charles-cooper merged commit a8382f5 into vyperlang:master May 18, 2023
@charles-cooper charles-cooper deleted the fix/corrupted_immutables branch May 18, 2023 14:18
@charles-cooper charles-cooper added this to the v0.3.8 milestone May 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Immutable variables can be read before assignment
3 participants