Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
0.25.10.22.10.24.10.23.10.26.10.21.1· Vendor fix available
Issue
Impact Prior to the patch, when executing specific EVM opcodes related to memory operations that use evmcore::Memory::copylarge, the crate can over-allocate memory when it is not needed, making it possible for an attacker to perform denial-of-service attack. Patches The flaw was corrected in commit 19ade85. Users should upgrade to ==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, =0.26.1. Workarounds None. Please upgrade your evm crate version References Fix commit: https://github.com/rust-blockchain/evm/commit/19ade858c430ab13eb562764a870ac9f8506f8dd For more information If you have any questions or comments about this advisory: Open an issue in evm repo Email Wei
Recommended action: Upgrade to 0.26.1, 0.25.1, 0.24.1 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In rust-evm, a feature called recordexternaloperation was introduced, allowing library users to record custom gas changes. This feature can have some bogus interactions with the call stack. In particular, during finalization of a CREATE or CREATE2, in the case that the substack execution happens successfully, rust-evm will first commit the substate, and then call recordexternaloperation(Write(outcode.len())). If recordexternaloperation later fails, this error is returned to the parent call stack, instead of Succeeded. Yet, the substate commitment already happened. This causes smart contracts able to commit state changes, when the parent caller contract receives zero address (which usually indicates that the execution has failed). This issue only impacts library users with custom recordexternaloperation that returns errors. Patches The issue is patched in release 0.41.1. The commit can be seem here. Workarounds None. References Patch PR #264.
Recommended action: Upgrade to 0.41.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A custom stateful precompile can use the isstatic parameter to determine if the call is executed in a static context (via STATICCALL), and thus decide if stateful operations should be done. Previously, the passed isstatic parameter was incorrect -- it was only set to true if the call comes from a direct STATICCALL opcode. However, once a static call context is entered, it should stay static. The issue only impacts custom precompiles that actually uses isstatic. The maintainers estimate the usage is low. However, for those affected, it can lead to possible incorrect state transitions. Patches PR: https://github.com/rust-blockchain/evm/pull/133 Released in v0.36.0. Older patch versions can be released on request if anyone needs them. Simply contact @sorpaas by email to request it. For more information If you have any questions or comments about this advisory: Open an issue in evm repo Email Wei at wei@that.world
Recommended action: Upgrade to 0.36.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In evm crate < 0.31.0, JUMPI opcode's condition is checked after the destination validity check. However, according to Geth and OpenEthereum, the condition check should happen before the destination validity check. Patches This is a high severity security advisory if you use evm crate for Ethereum mainnet. In this case, you should update your library dependency immediately to on or after 0.31.0. This is a low severity security advisory if you use evm crate in Frontier or in a standalone blockchain, because there's no security exploit possible with this advisory. It is not recommended to update to on or after 0.31.0 until all the normal chain upgrade preparations have been done. If you use Frontier or other pallet-evm based Substrate blockchain, please ensure to update your specversion before updating this. For other blockchains, please make sure to follow a hard-fork process before you update this. Workarounds If you are dependent on an older version of evm and cannot update…
Recommended action: Upgrade to 0.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.