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
During codegen stage, Vyper compiler does a incorrect unwrap to constant Bytes and String variables, later causing the compiler to panic.
Vulnerability Details
While parsing Name and Attribute expressions in codegen stage, if the referenced variable is mark as a constant, then Expr.parse_value_expr will be called to directly setup IRnode from the expression assigned to the constant variable.
After the IRnode is initialized, it calls unwrap_location to unwrap the variable to its value (as opposed to a pointer).
# Parse an expression that results in a value@classmethoddefparse_value_expr(cls, expr, context):
returnunwrap_location(cls(expr, context).ir_node)
The constant Bytes / String is initialized by Expr._make_bytelike, and their IR node location will be set to MEMORY. Therefore, if a constant Bytes / String is provided to Expr.parse_Name, an incorrect IRnode will be generated, as there is no valid reason to directly unwrap a Bytes / String into single value.
Fortunately, the incorrect unwraps will never make it's way into compiled bytecodes. unwrap_location will clean up the .location field of IRnode, and any access to the Bytes / String variable will either call bytes_data_ptr or get_bytearray_length. Both will panic if the variable passed to them does not have .location field.
Impact Details
credits: @anatomist (Whitehat) for Attackathon | Ethereum Protocol
reportid: #38581
Brief/Intro
During codegen stage, Vyper compiler does a incorrect unwrap to constant Bytes and String variables, later causing the compiler to panic.
Vulnerability Details
While parsing Name and Attribute expressions in codegen stage, if the referenced variable is mark as a constant, then Expr.parse_value_expr will be called to directly setup IRnode from the expression assigned to the constant variable.
After the IRnode is initialized, it calls unwrap_location to unwrap the variable to its value (as opposed to a pointer).
The constant Bytes / String is initialized by Expr._make_bytelike, and their IR node location will be set to MEMORY. Therefore, if a constant Bytes / String is provided to Expr.parse_Name, an incorrect IRnode will be generated, as there is no valid reason to directly unwrap a Bytes / String into single value.
Fortunately, the incorrect unwraps will never make it's way into compiled bytecodes. unwrap_location will clean up the .location field of IRnode, and any access to the Bytes / String variable will either call bytes_data_ptr or get_bytearray_length. Both will panic if the variable passed to them does not have .location field.
Impact Details
Compiler panics when it shouldn't.
References
vyper/vyper/codegen/expr.py
Line 197 in a29b49d
vyper/vyper/codegen/expr.py
Line 820 in a29b49d
Proof of Concept
The text was updated successfully, but these errors were encountered: