Charles-Cooper

Name of the Vulnerable Software and Affected Versions: Vyper versions up to and including 0.4.2rc1 Description: The issue concerns the `slice()` builtin in Vyper, which can elide side effects when the output length is 0 and the source bytestring is a builtin, such as `msg.data` or `<address>.code`. This occurs because the check for `length >= 1` is skipped for these source locations. As a result, a 0-length bytestring constructed with `slice()` can be passed to `make byte array copier`, which elides evaluation of its source argument when the max length is 0. This can lead to side effects in the `start` argument being elided when the `length` argument is 0. Recommendations: For versions up to and including 0.4.2rc1, consider updating to version 0.4.2, which is expected to include the fix that disallows any invocation of `slice()` with length 0. As a temporary workaround, avoid using the `slice()` function with a length of 0, especially when the source is `msg.data` or `<address>.code`, to prevent potential side effects from being elided.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.4.1 **Description** The issue arises from how Vyper handles AugAssign statements, specifically when the target is an access to a DynArray and the right-hand side (rhs) modifies the array. In such cases, the cached target evaluates first, and the bounds check is not re-evaluated during the write portion of the statement. This can lead to out-of-bounds access. For example, the code `a[1] += a.pop()` is evaluated as if `a[1]` is accessed before `a.pop()` modifies the array, bypassing the bounds check that would occur if `a[1]` were accessed after `a.pop()`. **Recommendations** For versions prior to 0.4.1, upgrade to version 0.4.1 or later to address this issue. At the moment, there is no information about other workarounds for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.4.1 **Description** The issue arises from the improper handling of oscillating final states in the `sqrt()` function, which uses the babylonian method to calculate square roots of decimals. This can lead to `sqrt()` incorrectly returning rounded up results. The impact of this issue is considered low, as `sqrt()` is rarely used in the wild. However, since `sqrt()` can be used for determining boundary conditions, rounding down is preferred. **Recommendations** For versions prior to 0.4.1, upgrade to version 0.4.1 as soon as the patched release is available. As a temporary workaround, consider avoiding the use of the `sqrt()` function until a patch is available. Restrict the use of the `sqrt()` function in critical calculations to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.0 **Description** The issue concerns the ` default ()` function not respecting the `@nonreentrancy` decorator, and the lock not being emitted. This is a known bug with low impact, as using a lock on a `default` function is a sparsely used pattern. No vulnerable production contracts were found. **Recommendations** For versions prior to 0.3.0, update to version 0.3.0 or later to resolve the issue. As a temporary workaround, consider avoiding the use of the `@nonreentrancy` decorator on ` default ()` functions until a patch is applied.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.3.10 and prior **Description** Using the `create from blueprint` builtin can result in a double eval vulnerability when `raw args=True` and the `args` argument has side-effects. The ` build create IR` function of the `create from blueprint` builtin doesn't cache the mentioned `args` argument to the stack, allowing it to be evaluated multiple times. No vulnerable production contracts were found, and double evaluation of side-effects should be easily discoverable in client tests, resulting in a low impact. **Recommendations** For Vyper versions 0.3.10 and prior, as a temporary workaround, consider disabling the `create from blueprint` builtin with `raw args=True` until a patch is available. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.8 **Description** The issue affects contracts containing large arrays, which might underallocate the number of slots they need by 1. This occurs due to a calculation error in determining the required slots for a storage variable, which uses `math.ceil(type .size in bytes / 32)`. The intermediate floating point step can produce a rounding error if there are enough bits set in the IEEE-754 mantissa. Specifically, if `type .size in bytes` is large (> 2**46) and slightly less than a power of 2, the calculation can overestimate the required slots, while if `type .size in bytes` is slightly more than a power of 2, it can underestimate the required slots. This can lead to overwriting of variables, as demonstrated by example contracts. **Recommendations** For versions prior to 0.3.8, update to version 0.3.8 to resolve the issue. As a temporary workaround, consider reviewing contracts for large arrays and manually verifying the allocation of slots to prevent potential overwriting of variables. Restrict access to contracts containing large arrays to minimize the risk of exploitation until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.10 **Description** The ` abi decode()` function in Vyper does not validate input when it is nested in an expression, allowing for bounds checking to be bypassed and resulting in incorrect results. This can be triggered by constructing specific examples where the output of ` abi decode` is not internally passed to input validating routines. **Recommendations** For versions prior to 0.3.10, update to version 0.3.10 to resolve the issue. As a temporary workaround, consider avoiding the use of ` abi decode()` in nested expressions until the patch is applied. Restrict access to the ` abi decode()` function to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.2.9 through 0.3.9 **Description** The issue concerns locks of the type `@nonreentrant("")` or `@nonreentrant('')` that do not produce reentrancy checks at runtime. This can be mitigated by ensuring the lock name is a non-empty string. **Recommendations** For versions 0.2.9 through 0.3.9, ensure the lock name is a non-empty string as a workaround until the issue is resolved by updating to version 0.3.10 or later. For version 0.3.10 and later, no additional action is required as the issue is fixed in this version.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.3.9 and prior **Description** The memory used by the builtins `raw call`, `create from blueprint`, and `create copy of` can be corrupted under certain conditions, leading to incorrect `calldata` in the sub-context or deploying incorrect bytecode. Each builtin has specific conditions that must be fulfilled for the corruption to happen, including the use of complex expressions that result in writing to memory. As of the time of publication, no patched version exists, and the issue is still being investigated. There might be other cases where the corruption might happen. When the builtin is being called from an `internal` function, the issue is not present if the function calling it wrote to memory before calling it. **Recommendations** For Vyper versions 0.3.9 and prior, as a temporary workaround, consider caching complex expressions in memory prior to the call to the builtin. For example, in the case of `create from blueprint`, cache the `salt` value in memory before passing it to the builtin. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper (affected versions not specified) **Description** The order of evaluation of the arguments of the builtin functions `uint256 addmod`, `uint256 mulmod`, `ecadd`, and `ecmul` does not follow source order. This behavior is problematic when the evaluation of one of the arguments produces side effects that other arguments depend on. For `uint256 addmod(a,b,c)` and `uint256 mulmod(a,b,c)`, the order is `c,a,b`. For `ecadd(a,b)` and `ecmul(a,b)`, the order is `b,a`. **Recommendations** As a temporary workaround, consider ensuring that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects when using builtins from the list above. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper (affected versions not specified) **Description** The Vyper compiler evaluates arguments from right to left instead of left to right for certain expressions, including `unsafe add, unsafe sub, unsafe mul, unsafe div, pow mod256, |, &, ^ (bitwise operators), bitwise or (deprecated), bitwise and (deprecated), bitwise xor (deprecated), raw call, <, >, <=, >=, ==, !=, in, not in (when lhs and rhs are enums)`. This behavior becomes a problem when the evaluation of one argument produces side effects that other arguments depend on. Expressions that can produce side effects include state modifying external calls, state modifying internal calls, `raw call`, `pop()` when used on a Dynamic Array stored in the storage, `create minimal proxy to`, `create copy of`, and `create from blueprint`. **Recommendations** As a temporary workaround, consider ensuring that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.10 **Description** The ecrecover precompile in Vyper does not fill the output buffer if the signature does not verify. However, the ecrecover builtin will still return whatever is at memory location 0. This means that if the compiler has been convinced to write to the 0 memory location with specially crafted data just before the ecrecover, a signature check might pass on an invalid signature. **Recommendations** For versions prior to 0.3.10, update to version 0.3.10 to resolve the issue. As a temporary workaround, consider restricting the use of the ecrecover builtin until a patch is applied. Avoid using the ecrecover operation with immutable reads or hashmap accesses that could write to the 0 memory location.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.8 **Description** In contracts with more than one regular nonpayable function, it is possible to send funds to the default function, even if the default function is marked `nonpayable`. This issue was fixed by the removal of the global `calldatasize` check. **Recommendations** For versions prior to 0.3.8, upgrade to version 0.3.8. For users unable to upgrade, avoid use of nonpayable default functions.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.8 **Description** The issue occurs during codegen when the length word of a dynarray is written before the data. This can result in out-of-bounds array access when the dynarray is on both the lhs and rhs of an assignment, potentially causing data corruption across call frames. The expected behavior is to revert due to out-of-bounds array access. **Recommendations** For versions prior to 0.3.8, update to version 0.3.8 to resolve the issue. As a temporary workaround, consider avoiding assignments where a dynarray is on both the lhs and rhs to minimize the risk of exploitation. Restrict the use of dynarrays in critical functions until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.4 **Description** The issue arises when calling an external contract with no return value, potentially resulting in the contract address being evaluated twice, including any side effects. This could lead to incorrect outcomes for contracts. The problem is usually an efficiency issue but can cause double evaluation of side effects if the contract address evaluation has side effects. **Recommendations** For versions prior to 0.3.4, update to version 0.3.4 or later to resolve the issue. As a temporary workaround, consider assigning contract addresses to variables to avoid double evaluation of side effects. For example, instead of `Foo(Foo(msg.sender).bar()).foo()`, use `t: Foo = Foo(msg.sender).bar()` and then `t.foo()`.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.2 **Description** The issue arises when importing a function from a JSON interface that returns `bytes`, generating bytecode that does not clamp the bytes length, potentially resulting in a buffer overrun. There are no known real-world incidents or estimated numbers of affected devices mentioned. **Recommendations** For versions prior to 0.3.2, upgrade to version 0.3.2 or later to resolve the issue. As a temporary workaround, consider using .vy interfaces instead of importing from JSON interfaces that return `bytes`.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.3.1 and prior **Description** The issue arises from the comparison of bytestrings, which can yield incorrect results due to the presence of dirty bytes or the lack of length comparison. Specifically, two bytestrings can compare as equal even if one ends with a null byte (`x00`) because the comparison does not account for the length of the bytestrings. This can lead to incorrect evaluations, such as `b1 == b2` returning `True` when `b1` and `b2` are not identical. **Recommendations** For Vyper versions 0.3.1 and prior, update to version 0.3.2 or later, which is expected to include the patch for this issue. At the moment, there is no information about other workarounds for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.0 **Description** The issue occurs when performing a function call inside a literal struct, resulting in a memory corruption problem due to an incorrect pointer to the top of the stack. **Recommendations** For versions prior to 0.3.0, update to version 0.3.0 to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.0 **Description** The issue arises from external functions not properly validating the bounds of decimal arguments, leading to potential logic errors. **Recommendations** For versions prior to 0.3.0, update to version 0.3.0 to resolve the issue. As a temporary workaround, consider avoiding the use of decimal arguments in external functions until the issue is resolved.