vyper

Impact

the slice() builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (msg.data or <address>.code). the reason is that for these source locations, the check that length >= 1 is skipped: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L315-L319

the result is that 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: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/codegen/core.py#L189-L191

the impact is that side effects in the start argument may be elided when the length argument is 0, e.g. slice(msg.data, self.do_side_effect(), 0).

the following example illustrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[10]:
    b: Bytes[10] = slice(msg.data, self.side_effect(), 0)
    return b

def side_effect() -> uint256:
    self.counter += 1
    return 0

the severity assigned is low, since this is not a very useful pattern and unlikely to be found in user code.

Patches

the fix is tracked in https://github.com/vyperlang/vyper/pull/4645, which disallows any invocation of slice() with length 0, including for the ad hoc locations discussed in this advisory.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Impact

concat() may skip evaluation of side effects when the length of an argument is zero. this is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L560-L562

in practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal b""; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. b"" if self.do_some_side_effect() else b"".

the following example demonstrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[256]:
    a: Bytes[256] = concat(b"" if self.sideeffect() else b"", b"aaaa")
    return a

def sideeffect() -> bool:
    self.counter += 1
    return True

the severity assigned is low, since, as mentioned, this would be a very unusual pattern in user-code.

Patches

fix is tracked in https://github.com/vyperlang/vyper/pull/4644

Workarounds

don't have side effects in expressions which construct zero-length bytestrings.

References

Are there any links users can visit to find out more?

Impact

the slice() builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (msg.data or <address>.code). the reason is that for these source locations, the check that length >= 1 is skipped: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L315-L319

the result is that 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: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/codegen/core.py#L189-L191

the impact is that side effects in the start argument may be elided when the length argument is 0, e.g. slice(msg.data, self.do_side_effect(), 0).

the following example illustrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[10]:
    b: Bytes[10] = slice(msg.data, self.side_effect(), 0)
    return b

def side_effect() -> uint256:
    self.counter += 1
    return 0

the severity assigned is low, since this is not a very useful pattern and unlikely to be found in user code.

Patches

the fix is tracked in https://github.com/vyperlang/vyper/pull/4645, which disallows any invocation of slice() with length 0, including for the ad hoc locations discussed in this advisory.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Impact

concat() may skip evaluation of side effects when the length of an argument is zero. this is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L560-L562

in practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal b""; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. b"" if self.do_some_side_effect() else b"".

the following example demonstrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[256]:
    a: Bytes[256] = concat(b"" if self.sideeffect() else b"", b"aaaa")
    return a

def sideeffect() -> bool:
    self.counter += 1
    return True

the severity assigned is low, since, as mentioned, this would be a very unusual pattern in user-code.

Patches

fix is tracked in https://github.com/vyperlang/vyper/pull/4644

Workarounds

don't have side effects in expressions which construct zero-length bytestrings.

References

Are there any links users can visit to find out more?

Impact

the slice() builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (msg.data or <address>.code). the reason is that for these source locations, the check that length >= 1 is skipped: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L315-L319

the result is that 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: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/codegen/core.py#L189-L191

the impact is that side effects in the start argument may be elided when the length argument is 0, e.g. slice(msg.data, self.do_side_effect(), 0).

the following example illustrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[10]:
    b: Bytes[10] = slice(msg.data, self.side_effect(), 0)
    return b

def side_effect() -> uint256:
    self.counter += 1
    return 0

the severity assigned is low, since this is not a very useful pattern and unlikely to be found in user code.

Patches

the fix is tracked in https://github.com/vyperlang/vyper/pull/4645, which disallows any invocation of slice() with length 0, including for the ad hoc locations discussed in this advisory.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Impact

concat() may skip evaluation of side effects when the length of an argument is zero. this is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L560-L562

in practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal b""; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. b"" if self.do_some_side_effect() else b"".

the following example demonstrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[256]:
    a: Bytes[256] = concat(b"" if self.sideeffect() else b"", b"aaaa")
    return a

def sideeffect() -> bool:
    self.counter += 1
    return True

the severity assigned is low, since, as mentioned, this would be a very unusual pattern in user-code.

Patches

fix is tracked in https://github.com/vyperlang/vyper/pull/4644

Workarounds

don't have side effects in expressions which construct zero-length bytestrings.

References

Are there any links users can visit to find out more?

Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. for s: uint256 in ([read(), read()] if True else [])) may interleave reads with writes in the loop body.

The fix is tracked in https://github.com/vyperlang/vyper/pull/4488.

Vulnerability Details

Vyper for loops allow two kinds of iterator targets, namely the range() builtin and an iterable type, like SArray and DArray.

During codegen, iterable lists are required to not produce any side-effects (in the following code, range_scope forces iter_list to be parsed in a constant context, which is checked against is_constant).

def _parse_For_list(self):
    with self.context.range_scope():
        iter_list = Expr(self.stmt.iter, self.context).ir_node
    ...

def range_scope(self):
    prev_value = self.in_range_expr
    self.in_range_expr = True
    yield
    self.in_range_expr = prev_value

def is_constant(self):
    return self.constancy is Constancy.Constant or self.in_range_expr

However, this does not prevent the iterator from consuming side effects provided by the body of the loop. For dynamic arrays, the compiler simply panics:

x: DynArray[uint256, 3]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.usesideeffect()):
        pass

@view
def usesideeffect() -> DynArray[uint256, 3]:
    return self.x

For SArrays on the other hand, iter_list is instantiated in the body of a repeat ir, so it can be evaluated several times.

Here are three illustrating examples. In the first example, the following test case pre-evaluates the iter list and stores the result to a temporary list in memory. So the list is only evaluated once, before entry into the loop body, and the log output will be 0, 0, 0.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in [self.usesideeffect(), self.usesideeffect(), self.usesideeffect()]:
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

However, in the next two examples, because the iterator target is not a list literal, it will be evaluated in the loop body. In the second example, iter_list is an ifexp, thus it will be evaluated lazily in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in ([self.usesideeffect(), self.usesideeffect(), self.usesideeffect()] if True else self.otherclause()):
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

In the third example, iter_list is also an ifexp, thus it will only be evaluated in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256[3]

@deploy
def __init__():
    self.x = [0, 0, 0]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.otherclause()):
        self.x[0] += 1
        self.x[1] += 1
        self.x[2] += 1
        log I(i)

@view
def usesideeffect() -> uint256[3]:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a.pop()

is equivalent to:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a[len(a) - 1]
    a.pop()

rather than:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    s: uint256 = a[1]
    t: uint256 = a.pop()
    a[1] = s + t  # reverts due to oob access

Vyper's sqrt() builtin uses the babylonian method to calculate square roots of decimals. Unfortunately, improper handling of the oscillating final states may lead to sqrt incorrectly returning rounded up results.

the fix is tracked in https://github.com/vyperlang/vyper/pull/4486

Vulnerability Details

Vyper injects the following code to handle calculation of decimal sqrt. x is the input provided by user.

assert x >= 0.0
z: decimal = 0.0

if x == 0.0:
    z = 0.0
else:
    z = x / 2.0 + 0.5
    y: decimal = x

    for i: uint256 in range(256):
        if z == y:
            break
        y = z
        z = (x / z + z) / 2.0

Notably, the terminal condition of the algorithm is either z_cur == z_prev, or the algorithm runs for 256 rounds.

However, for certain inputs, z might actually oscillate between N and N + epsilon, where N ** 2 <= x < (N + epsilon) ** 2. This means that the current behavior does not define whether it will round up or down to the nearest epsilon.

The example snippet here returns 0.9999999999, the rounded up result for sqrt(0.9999999998). This is due to the oscillation ending in N + epsilon instead of N.

@external
def test():
    d: decimal = 0.9999999998
    r: decimal = sqrt(d)    #this will be 0.9999999999

Note that sqrt() diverges from isqrt() here -- isqrt() consistently rounds down, so it is not subject to the same issue.

Impact Details

Since sqrt() can be used for determining boundary conditions, rounding down is preferred. However, since sqrt() is used very rarely in the wild, this advisory has been assigned an impact of low.

Vyper is a Pythonic Smart Contract Language for the EVM. When the Vyper Compiler uses the precompiles EcRecover (0x1) and Identity (0x4), the success flag of the call is not checked. As a consequence an attacker can provide a specific amount of gas to make these calls fail but let the overall execution continue. Then the execution result can be incorrect. Based on EVM's rules, after the failed precompile the remaining code has only 1/64 of the pre-call-gas left (as 63/64 were forwarded and spent). Hence, only fairly simple executions can follow the failed precompile calls. Therefore, we found no significantly impacted real-world contracts. None the less an advisory has been made out of an abundance of caution. There are no actions for users to take.

Impact

the slice() builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (msg.data or <address>.code). the reason is that for these source locations, the check that length >= 1 is skipped: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L315-L319

the result is that 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: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/codegen/core.py#L189-L191

the impact is that side effects in the start argument may be elided when the length argument is 0, e.g. slice(msg.data, self.do_side_effect(), 0).

the following example illustrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[10]:
    b: Bytes[10] = slice(msg.data, self.side_effect(), 0)
    return b

def side_effect() -> uint256:
    self.counter += 1
    return 0

the severity assigned is low, since this is not a very useful pattern and unlikely to be found in user code.

Patches

the fix is tracked in https://github.com/vyperlang/vyper/pull/4645, which disallows any invocation of slice() with length 0, including for the ad hoc locations discussed in this advisory.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Impact

concat() may skip evaluation of side effects when the length of an argument is zero. this is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L560-L562

in practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal b""; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. b"" if self.do_some_side_effect() else b"".

the following example demonstrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[256]:
    a: Bytes[256] = concat(b"" if self.sideeffect() else b"", b"aaaa")
    return a

def sideeffect() -> bool:
    self.counter += 1
    return True

the severity assigned is low, since, as mentioned, this would be a very unusual pattern in user-code.

Patches

fix is tracked in https://github.com/vyperlang/vyper/pull/4644

Workarounds

don't have side effects in expressions which construct zero-length bytestrings.

References

Are there any links users can visit to find out more?

Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. for s: uint256 in ([read(), read()] if True else [])) may interleave reads with writes in the loop body.

The fix is tracked in https://github.com/vyperlang/vyper/pull/4488.

Vulnerability Details

Vyper for loops allow two kinds of iterator targets, namely the range() builtin and an iterable type, like SArray and DArray.

During codegen, iterable lists are required to not produce any side-effects (in the following code, range_scope forces iter_list to be parsed in a constant context, which is checked against is_constant).

def _parse_For_list(self):
    with self.context.range_scope():
        iter_list = Expr(self.stmt.iter, self.context).ir_node
    ...

def range_scope(self):
    prev_value = self.in_range_expr
    self.in_range_expr = True
    yield
    self.in_range_expr = prev_value

def is_constant(self):
    return self.constancy is Constancy.Constant or self.in_range_expr

However, this does not prevent the iterator from consuming side effects provided by the body of the loop. For dynamic arrays, the compiler simply panics:

x: DynArray[uint256, 3]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.usesideeffect()):
        pass

@view
def usesideeffect() -> DynArray[uint256, 3]:
    return self.x

For SArrays on the other hand, iter_list is instantiated in the body of a repeat ir, so it can be evaluated several times.

Here are three illustrating examples. In the first example, the following test case pre-evaluates the iter list and stores the result to a temporary list in memory. So the list is only evaluated once, before entry into the loop body, and the log output will be 0, 0, 0.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in [self.usesideeffect(), self.usesideeffect(), self.usesideeffect()]:
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

However, in the next two examples, because the iterator target is not a list literal, it will be evaluated in the loop body. In the second example, iter_list is an ifexp, thus it will be evaluated lazily in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in ([self.usesideeffect(), self.usesideeffect(), self.usesideeffect()] if True else self.otherclause()):
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

In the third example, iter_list is also an ifexp, thus it will only be evaluated in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256[3]

@deploy
def __init__():
    self.x = [0, 0, 0]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.otherclause()):
        self.x[0] += 1
        self.x[1] += 1
        self.x[2] += 1
        log I(i)

@view
def usesideeffect() -> uint256[3]:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a.pop()

is equivalent to:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a[len(a) - 1]
    a.pop()

rather than:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    s: uint256 = a[1]
    t: uint256 = a.pop()
    a[1] = s + t  # reverts due to oob access

Vyper's sqrt() builtin uses the babylonian method to calculate square roots of decimals. Unfortunately, improper handling of the oscillating final states may lead to sqrt incorrectly returning rounded up results.

the fix is tracked in https://github.com/vyperlang/vyper/pull/4486

Vulnerability Details

Vyper injects the following code to handle calculation of decimal sqrt. x is the input provided by user.

assert x >= 0.0
z: decimal = 0.0

if x == 0.0:
    z = 0.0
else:
    z = x / 2.0 + 0.5
    y: decimal = x

    for i: uint256 in range(256):
        if z == y:
            break
        y = z
        z = (x / z + z) / 2.0

Notably, the terminal condition of the algorithm is either z_cur == z_prev, or the algorithm runs for 256 rounds.

However, for certain inputs, z might actually oscillate between N and N + epsilon, where N ** 2 <= x < (N + epsilon) ** 2. This means that the current behavior does not define whether it will round up or down to the nearest epsilon.

The example snippet here returns 0.9999999999, the rounded up result for sqrt(0.9999999998). This is due to the oscillation ending in N + epsilon instead of N.

@external
def test():
    d: decimal = 0.9999999998
    r: decimal = sqrt(d)    #this will be 0.9999999999

Note that sqrt() diverges from isqrt() here -- isqrt() consistently rounds down, so it is not subject to the same issue.

Impact Details

Since sqrt() can be used for determining boundary conditions, rounding down is preferred. However, since sqrt() is used very rarely in the wild, this advisory has been assigned an impact of low.

Vyper is a Pythonic Smart Contract Language for the EVM. When the Vyper Compiler uses the precompiles EcRecover (0x1) and Identity (0x4), the success flag of the call is not checked. As a consequence an attacker can provide a specific amount of gas to make these calls fail but let the overall execution continue. Then the execution result can be incorrect. Based on EVM's rules, after the failed precompile the remaining code has only 1/64 of the pre-call-gas left (as 63/64 were forwarded and spent). Hence, only fairly simple executions can follow the failed precompile calls. Therefore, we found no significantly impacted real-world contracts. None the less an advisory has been made out of an abundance of caution. There are no actions for users to take.

Impact

the slice() builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (msg.data or <address>.code). the reason is that for these source locations, the check that length >= 1 is skipped: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L315-L319

the result is that 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: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/codegen/core.py#L189-L191

the impact is that side effects in the start argument may be elided when the length argument is 0, e.g. slice(msg.data, self.do_side_effect(), 0).

the following example illustrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[10]:
    b: Bytes[10] = slice(msg.data, self.side_effect(), 0)
    return b

def side_effect() -> uint256:
    self.counter += 1
    return 0

the severity assigned is low, since this is not a very useful pattern and unlikely to be found in user code.

Patches

the fix is tracked in https://github.com/vyperlang/vyper/pull/4645, which disallows any invocation of slice() with length 0, including for the ad hoc locations discussed in this advisory.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Impact

concat() may skip evaluation of side effects when the length of an argument is zero. this is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L560-L562

in practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal b""; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. b"" if self.do_some_side_effect() else b"".

the following example demonstrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[256]:
    a: Bytes[256] = concat(b"" if self.sideeffect() else b"", b"aaaa")
    return a

def sideeffect() -> bool:
    self.counter += 1
    return True

the severity assigned is low, since, as mentioned, this would be a very unusual pattern in user-code.

Patches

fix is tracked in https://github.com/vyperlang/vyper/pull/4644

Workarounds

don't have side effects in expressions which construct zero-length bytestrings.

References

Are there any links users can visit to find out more?

Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. for s: uint256 in ([read(), read()] if True else [])) may interleave reads with writes in the loop body.

The fix is tracked in https://github.com/vyperlang/vyper/pull/4488.

Vulnerability Details

Vyper for loops allow two kinds of iterator targets, namely the range() builtin and an iterable type, like SArray and DArray.

During codegen, iterable lists are required to not produce any side-effects (in the following code, range_scope forces iter_list to be parsed in a constant context, which is checked against is_constant).

def _parse_For_list(self):
    with self.context.range_scope():
        iter_list = Expr(self.stmt.iter, self.context).ir_node
    ...

def range_scope(self):
    prev_value = self.in_range_expr
    self.in_range_expr = True
    yield
    self.in_range_expr = prev_value

def is_constant(self):
    return self.constancy is Constancy.Constant or self.in_range_expr

However, this does not prevent the iterator from consuming side effects provided by the body of the loop. For dynamic arrays, the compiler simply panics:

x: DynArray[uint256, 3]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.usesideeffect()):
        pass

@view
def usesideeffect() -> DynArray[uint256, 3]:
    return self.x

For SArrays on the other hand, iter_list is instantiated in the body of a repeat ir, so it can be evaluated several times.

Here are three illustrating examples. In the first example, the following test case pre-evaluates the iter list and stores the result to a temporary list in memory. So the list is only evaluated once, before entry into the loop body, and the log output will be 0, 0, 0.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in [self.usesideeffect(), self.usesideeffect(), self.usesideeffect()]:
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

However, in the next two examples, because the iterator target is not a list literal, it will be evaluated in the loop body. In the second example, iter_list is an ifexp, thus it will be evaluated lazily in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in ([self.usesideeffect(), self.usesideeffect(), self.usesideeffect()] if True else self.otherclause()):
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

In the third example, iter_list is also an ifexp, thus it will only be evaluated in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256[3]

@deploy
def __init__():
    self.x = [0, 0, 0]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.otherclause()):
        self.x[0] += 1
        self.x[1] += 1
        self.x[2] += 1
        log I(i)

@view
def usesideeffect() -> uint256[3]:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a.pop()

is equivalent to:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a[len(a) - 1]
    a.pop()

rather than:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    s: uint256 = a[1]
    t: uint256 = a.pop()
    a[1] = s + t  # reverts due to oob access

Vyper's sqrt() builtin uses the babylonian method to calculate square roots of decimals. Unfortunately, improper handling of the oscillating final states may lead to sqrt incorrectly returning rounded up results.

the fix is tracked in https://github.com/vyperlang/vyper/pull/4486

Vulnerability Details

Vyper injects the following code to handle calculation of decimal sqrt. x is the input provided by user.

assert x >= 0.0
z: decimal = 0.0

if x == 0.0:
    z = 0.0
else:
    z = x / 2.0 + 0.5
    y: decimal = x

    for i: uint256 in range(256):
        if z == y:
            break
        y = z
        z = (x / z + z) / 2.0

Notably, the terminal condition of the algorithm is either z_cur == z_prev, or the algorithm runs for 256 rounds.

However, for certain inputs, z might actually oscillate between N and N + epsilon, where N ** 2 <= x < (N + epsilon) ** 2. This means that the current behavior does not define whether it will round up or down to the nearest epsilon.

The example snippet here returns 0.9999999999, the rounded up result for sqrt(0.9999999998). This is due to the oscillation ending in N + epsilon instead of N.

@external
def test():
    d: decimal = 0.9999999998
    r: decimal = sqrt(d)    #this will be 0.9999999999

Note that sqrt() diverges from isqrt() here -- isqrt() consistently rounds down, so it is not subject to the same issue.

Impact Details

Since sqrt() can be used for determining boundary conditions, rounding down is preferred. However, since sqrt() is used very rarely in the wild, this advisory has been assigned an impact of low.

Vyper is a Pythonic Smart Contract Language for the EVM. When the Vyper Compiler uses the precompiles EcRecover (0x1) and Identity (0x4), the success flag of the call is not checked. As a consequence an attacker can provide a specific amount of gas to make these calls fail but let the overall execution continue. Then the execution result can be incorrect. Based on EVM's rules, after the failed precompile the remaining code has only 1/64 of the pre-call-gas left (as 63/64 were forwarded and spent). Hence, only fairly simple executions can follow the failed precompile calls. Therefore, we found no significantly impacted real-world contracts. None the less an advisory has been made out of an abundance of caution. There are no actions for users to take.

Impact

the slice() builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (msg.data or <address>.code). the reason is that for these source locations, the check that length >= 1 is skipped: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L315-L319

the result is that 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: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/codegen/core.py#L189-L191

the impact is that side effects in the start argument may be elided when the length argument is 0, e.g. slice(msg.data, self.do_side_effect(), 0).

the following example illustrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[10]:
    b: Bytes[10] = slice(msg.data, self.side_effect(), 0)
    return b

def side_effect() -> uint256:
    self.counter += 1
    return 0

the severity assigned is low, since this is not a very useful pattern and unlikely to be found in user code.

Patches

the fix is tracked in https://github.com/vyperlang/vyper/pull/4645, which disallows any invocation of slice() with length 0, including for the ad hoc locations discussed in this advisory.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Impact

concat() may skip evaluation of side effects when the length of an argument is zero. this is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L560-L562

in practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal b""; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. b"" if self.do_some_side_effect() else b"".

the following example demonstrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[256]:
    a: Bytes[256] = concat(b"" if self.sideeffect() else b"", b"aaaa")
    return a

def sideeffect() -> bool:
    self.counter += 1
    return True

the severity assigned is low, since, as mentioned, this would be a very unusual pattern in user-code.

Patches

fix is tracked in https://github.com/vyperlang/vyper/pull/4644

Workarounds

don't have side effects in expressions which construct zero-length bytestrings.

References

Are there any links users can visit to find out more?

Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. for s: uint256 in ([read(), read()] if True else [])) may interleave reads with writes in the loop body.

The fix is tracked in https://github.com/vyperlang/vyper/pull/4488.

Vulnerability Details

Vyper for loops allow two kinds of iterator targets, namely the range() builtin and an iterable type, like SArray and DArray.

During codegen, iterable lists are required to not produce any side-effects (in the following code, range_scope forces iter_list to be parsed in a constant context, which is checked against is_constant).

def _parse_For_list(self):
    with self.context.range_scope():
        iter_list = Expr(self.stmt.iter, self.context).ir_node
    ...

def range_scope(self):
    prev_value = self.in_range_expr
    self.in_range_expr = True
    yield
    self.in_range_expr = prev_value

def is_constant(self):
    return self.constancy is Constancy.Constant or self.in_range_expr

However, this does not prevent the iterator from consuming side effects provided by the body of the loop. For dynamic arrays, the compiler simply panics:

x: DynArray[uint256, 3]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.usesideeffect()):
        pass

@view
def usesideeffect() -> DynArray[uint256, 3]:
    return self.x

For SArrays on the other hand, iter_list is instantiated in the body of a repeat ir, so it can be evaluated several times.

Here are three illustrating examples. In the first example, the following test case pre-evaluates the iter list and stores the result to a temporary list in memory. So the list is only evaluated once, before entry into the loop body, and the log output will be 0, 0, 0.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in [self.usesideeffect(), self.usesideeffect(), self.usesideeffect()]:
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

However, in the next two examples, because the iterator target is not a list literal, it will be evaluated in the loop body. In the second example, iter_list is an ifexp, thus it will be evaluated lazily in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in ([self.usesideeffect(), self.usesideeffect(), self.usesideeffect()] if True else self.otherclause()):
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

In the third example, iter_list is also an ifexp, thus it will only be evaluated in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256[3]

@deploy
def __init__():
    self.x = [0, 0, 0]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.otherclause()):
        self.x[0] += 1
        self.x[1] += 1
        self.x[2] += 1
        log I(i)

@view
def usesideeffect() -> uint256[3]:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a.pop()

is equivalent to:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a[len(a) - 1]
    a.pop()

rather than:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    s: uint256 = a[1]
    t: uint256 = a.pop()
    a[1] = s + t  # reverts due to oob access

Vyper's sqrt() builtin uses the babylonian method to calculate square roots of decimals. Unfortunately, improper handling of the oscillating final states may lead to sqrt incorrectly returning rounded up results.

the fix is tracked in https://github.com/vyperlang/vyper/pull/4486

Vulnerability Details

Vyper injects the following code to handle calculation of decimal sqrt. x is the input provided by user.

assert x >= 0.0
z: decimal = 0.0

if x == 0.0:
    z = 0.0
else:
    z = x / 2.0 + 0.5
    y: decimal = x

    for i: uint256 in range(256):
        if z == y:
            break
        y = z
        z = (x / z + z) / 2.0

Notably, the terminal condition of the algorithm is either z_cur == z_prev, or the algorithm runs for 256 rounds.

However, for certain inputs, z might actually oscillate between N and N + epsilon, where N ** 2 <= x < (N + epsilon) ** 2. This means that the current behavior does not define whether it will round up or down to the nearest epsilon.

The example snippet here returns 0.9999999999, the rounded up result for sqrt(0.9999999998). This is due to the oscillation ending in N + epsilon instead of N.

@external
def test():
    d: decimal = 0.9999999998
    r: decimal = sqrt(d)    #this will be 0.9999999999

Note that sqrt() diverges from isqrt() here -- isqrt() consistently rounds down, so it is not subject to the same issue.

Impact Details

Since sqrt() can be used for determining boundary conditions, rounding down is preferred. However, since sqrt() is used very rarely in the wild, this advisory has been assigned an impact of low.

Vyper is a Pythonic Smart Contract Language for the EVM. When the Vyper Compiler uses the precompiles EcRecover (0x1) and Identity (0x4), the success flag of the call is not checked. As a consequence an attacker can provide a specific amount of gas to make these calls fail but let the overall execution continue. Then the execution result can be incorrect. Based on EVM's rules, after the failed precompile the remaining code has only 1/64 of the pre-call-gas left (as 63/64 were forwarded and spent). Hence, only fairly simple executions can follow the failed precompile calls. Therefore, we found no significantly impacted real-world contracts. None the less an advisory has been made out of an abundance of caution. There are no actions for users to take.

Impact

the slice() builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (msg.data or <address>.code). the reason is that for these source locations, the check that length >= 1 is skipped: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L315-L319

the result is that 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: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/codegen/core.py#L189-L191

the impact is that side effects in the start argument may be elided when the length argument is 0, e.g. slice(msg.data, self.do_side_effect(), 0).

the following example illustrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[10]:
    b: Bytes[10] = slice(msg.data, self.side_effect(), 0)
    return b

def side_effect() -> uint256:
    self.counter += 1
    return 0

the severity assigned is low, since this is not a very useful pattern and unlikely to be found in user code.

Patches

the fix is tracked in https://github.com/vyperlang/vyper/pull/4645, which disallows any invocation of slice() with length 0, including for the ad hoc locations discussed in this advisory.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Impact

concat() may skip evaluation of side effects when the length of an argument is zero. this is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L560-L562

in practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal b""; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. b"" if self.do_some_side_effect() else b"".

the following example demonstrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[256]:
    a: Bytes[256] = concat(b"" if self.sideeffect() else b"", b"aaaa")
    return a

def sideeffect() -> bool:
    self.counter += 1
    return True

the severity assigned is low, since, as mentioned, this would be a very unusual pattern in user-code.

Patches

fix is tracked in https://github.com/vyperlang/vyper/pull/4644

Workarounds

don't have side effects in expressions which construct zero-length bytestrings.

References

Are there any links users can visit to find out more?

Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. for s: uint256 in ([read(), read()] if True else [])) may interleave reads with writes in the loop body.

The fix is tracked in https://github.com/vyperlang/vyper/pull/4488.

Vulnerability Details

Vyper for loops allow two kinds of iterator targets, namely the range() builtin and an iterable type, like SArray and DArray.

During codegen, iterable lists are required to not produce any side-effects (in the following code, range_scope forces iter_list to be parsed in a constant context, which is checked against is_constant).

def _parse_For_list(self):
    with self.context.range_scope():
        iter_list = Expr(self.stmt.iter, self.context).ir_node
    ...

def range_scope(self):
    prev_value = self.in_range_expr
    self.in_range_expr = True
    yield
    self.in_range_expr = prev_value

def is_constant(self):
    return self.constancy is Constancy.Constant or self.in_range_expr

However, this does not prevent the iterator from consuming side effects provided by the body of the loop. For dynamic arrays, the compiler simply panics:

x: DynArray[uint256, 3]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.usesideeffect()):
        pass

@view
def usesideeffect() -> DynArray[uint256, 3]:
    return self.x

For SArrays on the other hand, iter_list is instantiated in the body of a repeat ir, so it can be evaluated several times.

Here are three illustrating examples. In the first example, the following test case pre-evaluates the iter list and stores the result to a temporary list in memory. So the list is only evaluated once, before entry into the loop body, and the log output will be 0, 0, 0.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in [self.usesideeffect(), self.usesideeffect(), self.usesideeffect()]:
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

However, in the next two examples, because the iterator target is not a list literal, it will be evaluated in the loop body. In the second example, iter_list is an ifexp, thus it will be evaluated lazily in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in ([self.usesideeffect(), self.usesideeffect(), self.usesideeffect()] if True else self.otherclause()):
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

In the third example, iter_list is also an ifexp, thus it will only be evaluated in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256[3]

@deploy
def __init__():
    self.x = [0, 0, 0]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.otherclause()):
        self.x[0] += 1
        self.x[1] += 1
        self.x[2] += 1
        log I(i)

@view
def usesideeffect() -> uint256[3]:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a.pop()

is equivalent to:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a[len(a) - 1]
    a.pop()

rather than:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    s: uint256 = a[1]
    t: uint256 = a.pop()
    a[1] = s + t  # reverts due to oob access

Vyper's sqrt() builtin uses the babylonian method to calculate square roots of decimals. Unfortunately, improper handling of the oscillating final states may lead to sqrt incorrectly returning rounded up results.

the fix is tracked in https://github.com/vyperlang/vyper/pull/4486

Vulnerability Details

Vyper injects the following code to handle calculation of decimal sqrt. x is the input provided by user.

assert x >= 0.0
z: decimal = 0.0

if x == 0.0:
    z = 0.0
else:
    z = x / 2.0 + 0.5
    y: decimal = x

    for i: uint256 in range(256):
        if z == y:
            break
        y = z
        z = (x / z + z) / 2.0

Notably, the terminal condition of the algorithm is either z_cur == z_prev, or the algorithm runs for 256 rounds.

However, for certain inputs, z might actually oscillate between N and N + epsilon, where N ** 2 <= x < (N + epsilon) ** 2. This means that the current behavior does not define whether it will round up or down to the nearest epsilon.

The example snippet here returns 0.9999999999, the rounded up result for sqrt(0.9999999998). This is due to the oscillation ending in N + epsilon instead of N.

@external
def test():
    d: decimal = 0.9999999998
    r: decimal = sqrt(d)    #this will be 0.9999999999

Note that sqrt() diverges from isqrt() here -- isqrt() consistently rounds down, so it is not subject to the same issue.

Impact Details

Since sqrt() can be used for determining boundary conditions, rounding down is preferred. However, since sqrt() is used very rarely in the wild, this advisory has been assigned an impact of low.

Vyper is a Pythonic Smart Contract Language for the EVM. When the Vyper Compiler uses the precompiles EcRecover (0x1) and Identity (0x4), the success flag of the call is not checked. As a consequence an attacker can provide a specific amount of gas to make these calls fail but let the overall execution continue. Then the execution result can be incorrect. Based on EVM's rules, after the failed precompile the remaining code has only 1/64 of the pre-call-gas left (as 63/64 were forwarded and spent). Hence, only fairly simple executions can follow the failed precompile calls. Therefore, we found no significantly impacted real-world contracts. None the less an advisory has been made out of an abundance of caution. There are no actions for users to take.

Impact

the slice() builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (msg.data or <address>.code). the reason is that for these source locations, the check that length >= 1 is skipped: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L315-L319

the result is that 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: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/codegen/core.py#L189-L191

the impact is that side effects in the start argument may be elided when the length argument is 0, e.g. slice(msg.data, self.do_side_effect(), 0).

the following example illustrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[10]:
    b: Bytes[10] = slice(msg.data, self.side_effect(), 0)
    return b

def side_effect() -> uint256:
    self.counter += 1
    return 0

the severity assigned is low, since this is not a very useful pattern and unlikely to be found in user code.

Patches

the fix is tracked in https://github.com/vyperlang/vyper/pull/4645, which disallows any invocation of slice() with length 0, including for the ad hoc locations discussed in this advisory.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Impact

concat() may skip evaluation of side effects when the length of an argument is zero. this is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L560-L562

in practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal b""; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. b"" if self.do_some_side_effect() else b"".

the following example demonstrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[256]:
    a: Bytes[256] = concat(b"" if self.sideeffect() else b"", b"aaaa")
    return a

def sideeffect() -> bool:
    self.counter += 1
    return True

the severity assigned is low, since, as mentioned, this would be a very unusual pattern in user-code.

Patches

fix is tracked in https://github.com/vyperlang/vyper/pull/4644

Workarounds

don't have side effects in expressions which construct zero-length bytestrings.

References

Are there any links users can visit to find out more?

Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. for s: uint256 in ([read(), read()] if True else [])) may interleave reads with writes in the loop body.

The fix is tracked in https://github.com/vyperlang/vyper/pull/4488.

Vulnerability Details

Vyper for loops allow two kinds of iterator targets, namely the range() builtin and an iterable type, like SArray and DArray.

During codegen, iterable lists are required to not produce any side-effects (in the following code, range_scope forces iter_list to be parsed in a constant context, which is checked against is_constant).

def _parse_For_list(self):
    with self.context.range_scope():
        iter_list = Expr(self.stmt.iter, self.context).ir_node
    ...

def range_scope(self):
    prev_value = self.in_range_expr
    self.in_range_expr = True
    yield
    self.in_range_expr = prev_value

def is_constant(self):
    return self.constancy is Constancy.Constant or self.in_range_expr

However, this does not prevent the iterator from consuming side effects provided by the body of the loop. For dynamic arrays, the compiler simply panics:

x: DynArray[uint256, 3]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.usesideeffect()):
        pass

@view
def usesideeffect() -> DynArray[uint256, 3]:
    return self.x

For SArrays on the other hand, iter_list is instantiated in the body of a repeat ir, so it can be evaluated several times.

Here are three illustrating examples. In the first example, the following test case pre-evaluates the iter list and stores the result to a temporary list in memory. So the list is only evaluated once, before entry into the loop body, and the log output will be 0, 0, 0.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in [self.usesideeffect(), self.usesideeffect(), self.usesideeffect()]:
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

However, in the next two examples, because the iterator target is not a list literal, it will be evaluated in the loop body. In the second example, iter_list is an ifexp, thus it will be evaluated lazily in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in ([self.usesideeffect(), self.usesideeffect(), self.usesideeffect()] if True else self.otherclause()):
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

In the third example, iter_list is also an ifexp, thus it will only be evaluated in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256[3]

@deploy
def __init__():
    self.x = [0, 0, 0]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.otherclause()):
        self.x[0] += 1
        self.x[1] += 1
        self.x[2] += 1
        log I(i)

@view
def usesideeffect() -> uint256[3]:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a.pop()

is equivalent to:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a[len(a) - 1]
    a.pop()

rather than:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    s: uint256 = a[1]
    t: uint256 = a.pop()
    a[1] = s + t  # reverts due to oob access

Vyper's sqrt() builtin uses the babylonian method to calculate square roots of decimals. Unfortunately, improper handling of the oscillating final states may lead to sqrt incorrectly returning rounded up results.

the fix is tracked in https://github.com/vyperlang/vyper/pull/4486

Vulnerability Details

Vyper injects the following code to handle calculation of decimal sqrt. x is the input provided by user.

assert x >= 0.0
z: decimal = 0.0

if x == 0.0:
    z = 0.0
else:
    z = x / 2.0 + 0.5
    y: decimal = x

    for i: uint256 in range(256):
        if z == y:
            break
        y = z
        z = (x / z + z) / 2.0

Notably, the terminal condition of the algorithm is either z_cur == z_prev, or the algorithm runs for 256 rounds.

However, for certain inputs, z might actually oscillate between N and N + epsilon, where N ** 2 <= x < (N + epsilon) ** 2. This means that the current behavior does not define whether it will round up or down to the nearest epsilon.

The example snippet here returns 0.9999999999, the rounded up result for sqrt(0.9999999998). This is due to the oscillation ending in N + epsilon instead of N.

@external
def test():
    d: decimal = 0.9999999998
    r: decimal = sqrt(d)    #this will be 0.9999999999

Note that sqrt() diverges from isqrt() here -- isqrt() consistently rounds down, so it is not subject to the same issue.

Impact Details

Since sqrt() can be used for determining boundary conditions, rounding down is preferred. However, since sqrt() is used very rarely in the wild, this advisory has been assigned an impact of low.

Vyper is a Pythonic Smart Contract Language for the EVM. When the Vyper Compiler uses the precompiles EcRecover (0x1) and Identity (0x4), the success flag of the call is not checked. As a consequence an attacker can provide a specific amount of gas to make these calls fail but let the overall execution continue. Then the execution result can be incorrect. Based on EVM's rules, after the failed precompile the remaining code has only 1/64 of the pre-call-gas left (as 63/64 were forwarded and spent). Hence, only fairly simple executions can follow the failed precompile calls. Therefore, we found no significantly impacted real-world contracts. None the less an advisory has been made out of an abundance of caution. There are no actions for users to take.

Impact

the slice() builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (msg.data or <address>.code). the reason is that for these source locations, the check that length >= 1 is skipped: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L315-L319

the result is that 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: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/codegen/core.py#L189-L191

the impact is that side effects in the start argument may be elided when the length argument is 0, e.g. slice(msg.data, self.do_side_effect(), 0).

the following example illustrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[10]:
    b: Bytes[10] = slice(msg.data, self.side_effect(), 0)
    return b

def side_effect() -> uint256:
    self.counter += 1
    return 0

the severity assigned is low, since this is not a very useful pattern and unlikely to be found in user code.

Patches

the fix is tracked in https://github.com/vyperlang/vyper/pull/4645, which disallows any invocation of slice() with length 0, including for the ad hoc locations discussed in this advisory.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Impact

concat() may skip evaluation of side effects when the length of an argument is zero. this is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L560-L562

in practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal b""; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. b"" if self.do_some_side_effect() else b"".

the following example demonstrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[256]:
    a: Bytes[256] = concat(b"" if self.sideeffect() else b"", b"aaaa")
    return a

def sideeffect() -> bool:
    self.counter += 1
    return True

the severity assigned is low, since, as mentioned, this would be a very unusual pattern in user-code.

Patches

fix is tracked in https://github.com/vyperlang/vyper/pull/4644

Workarounds

don't have side effects in expressions which construct zero-length bytestrings.

References

Are there any links users can visit to find out more?

Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. for s: uint256 in ([read(), read()] if True else [])) may interleave reads with writes in the loop body.

The fix is tracked in https://github.com/vyperlang/vyper/pull/4488.

Vulnerability Details

Vyper for loops allow two kinds of iterator targets, namely the range() builtin and an iterable type, like SArray and DArray.

During codegen, iterable lists are required to not produce any side-effects (in the following code, range_scope forces iter_list to be parsed in a constant context, which is checked against is_constant).

def _parse_For_list(self):
    with self.context.range_scope():
        iter_list = Expr(self.stmt.iter, self.context).ir_node
    ...

def range_scope(self):
    prev_value = self.in_range_expr
    self.in_range_expr = True
    yield
    self.in_range_expr = prev_value

def is_constant(self):
    return self.constancy is Constancy.Constant or self.in_range_expr

However, this does not prevent the iterator from consuming side effects provided by the body of the loop. For dynamic arrays, the compiler simply panics:

x: DynArray[uint256, 3]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.usesideeffect()):
        pass

@view
def usesideeffect() -> DynArray[uint256, 3]:
    return self.x

For SArrays on the other hand, iter_list is instantiated in the body of a repeat ir, so it can be evaluated several times.

Here are three illustrating examples. In the first example, the following test case pre-evaluates the iter list and stores the result to a temporary list in memory. So the list is only evaluated once, before entry into the loop body, and the log output will be 0, 0, 0.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in [self.usesideeffect(), self.usesideeffect(), self.usesideeffect()]:
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

However, in the next two examples, because the iterator target is not a list literal, it will be evaluated in the loop body. In the second example, iter_list is an ifexp, thus it will be evaluated lazily in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in ([self.usesideeffect(), self.usesideeffect(), self.usesideeffect()] if True else self.otherclause()):
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

In the third example, iter_list is also an ifexp, thus it will only be evaluated in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256[3]

@deploy
def __init__():
    self.x = [0, 0, 0]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.otherclause()):
        self.x[0] += 1
        self.x[1] += 1
        self.x[2] += 1
        log I(i)

@view
def usesideeffect() -> uint256[3]:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a.pop()

is equivalent to:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a[len(a) - 1]
    a.pop()

rather than:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    s: uint256 = a[1]
    t: uint256 = a.pop()
    a[1] = s + t  # reverts due to oob access

Vyper's sqrt() builtin uses the babylonian method to calculate square roots of decimals. Unfortunately, improper handling of the oscillating final states may lead to sqrt incorrectly returning rounded up results.

the fix is tracked in https://github.com/vyperlang/vyper/pull/4486

Vulnerability Details

Vyper injects the following code to handle calculation of decimal sqrt. x is the input provided by user.

assert x >= 0.0
z: decimal = 0.0

if x == 0.0:
    z = 0.0
else:
    z = x / 2.0 + 0.5
    y: decimal = x

    for i: uint256 in range(256):
        if z == y:
            break
        y = z
        z = (x / z + z) / 2.0

Notably, the terminal condition of the algorithm is either z_cur == z_prev, or the algorithm runs for 256 rounds.

However, for certain inputs, z might actually oscillate between N and N + epsilon, where N ** 2 <= x < (N + epsilon) ** 2. This means that the current behavior does not define whether it will round up or down to the nearest epsilon.

The example snippet here returns 0.9999999999, the rounded up result for sqrt(0.9999999998). This is due to the oscillation ending in N + epsilon instead of N.

@external
def test():
    d: decimal = 0.9999999998
    r: decimal = sqrt(d)    #this will be 0.9999999999

Note that sqrt() diverges from isqrt() here -- isqrt() consistently rounds down, so it is not subject to the same issue.

Impact Details

Since sqrt() can be used for determining boundary conditions, rounding down is preferred. However, since sqrt() is used very rarely in the wild, this advisory has been assigned an impact of low.

Vyper is a Pythonic Smart Contract Language for the EVM. When the Vyper Compiler uses the precompiles EcRecover (0x1) and Identity (0x4), the success flag of the call is not checked. As a consequence an attacker can provide a specific amount of gas to make these calls fail but let the overall execution continue. Then the execution result can be incorrect. Based on EVM's rules, after the failed precompile the remaining code has only 1/64 of the pre-call-gas left (as 63/64 were forwarded and spent). Hence, only fairly simple executions can follow the failed precompile calls. Therefore, we found no significantly impacted real-world contracts. None the less an advisory has been made out of an abundance of caution. There are no actions for users to take.

Impact

the slice() builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (msg.data or <address>.code). the reason is that for these source locations, the check that length >= 1 is skipped: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L315-L319

the result is that 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: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/codegen/core.py#L189-L191

the impact is that side effects in the start argument may be elided when the length argument is 0, e.g. slice(msg.data, self.do_side_effect(), 0).

the following example illustrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[10]:
    b: Bytes[10] = slice(msg.data, self.side_effect(), 0)
    return b

def side_effect() -> uint256:
    self.counter += 1
    return 0

the severity assigned is low, since this is not a very useful pattern and unlikely to be found in user code.

Patches

the fix is tracked in https://github.com/vyperlang/vyper/pull/4645, which disallows any invocation of slice() with length 0, including for the ad hoc locations discussed in this advisory.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Impact

concat() may skip evaluation of side effects when the length of an argument is zero. this is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero: https://github.com/vyperlang/vyper/blob/68b68c4b30c5ef2f312b4674676170b8a6eaa316/vyper/builtins/functions.py#L560-L562

in practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal b""; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. b"" if self.do_some_side_effect() else b"".

the following example demonstrates how the issue would look in user code

counter: public(uint256)

@external
def test() -> Bytes[256]:
    a: Bytes[256] = concat(b"" if self.sideeffect() else b"", b"aaaa")
    return a

def sideeffect() -> bool:
    self.counter += 1
    return True

the severity assigned is low, since, as mentioned, this would be a very unusual pattern in user-code.

Patches

fix is tracked in https://github.com/vyperlang/vyper/pull/4644

Workarounds

don't have side effects in expressions which construct zero-length bytestrings.

References

Are there any links users can visit to find out more?

Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. for s: uint256 in ([read(), read()] if True else [])) may interleave reads with writes in the loop body.

The fix is tracked in https://github.com/vyperlang/vyper/pull/4488.

Vulnerability Details

Vyper for loops allow two kinds of iterator targets, namely the range() builtin and an iterable type, like SArray and DArray.

During codegen, iterable lists are required to not produce any side-effects (in the following code, range_scope forces iter_list to be parsed in a constant context, which is checked against is_constant).

def _parse_For_list(self):
    with self.context.range_scope():
        iter_list = Expr(self.stmt.iter, self.context).ir_node
    ...

def range_scope(self):
    prev_value = self.in_range_expr
    self.in_range_expr = True
    yield
    self.in_range_expr = prev_value

def is_constant(self):
    return self.constancy is Constancy.Constant or self.in_range_expr

However, this does not prevent the iterator from consuming side effects provided by the body of the loop. For dynamic arrays, the compiler simply panics:

x: DynArray[uint256, 3]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.usesideeffect()):
        pass

@view
def usesideeffect() -> DynArray[uint256, 3]:
    return self.x

For SArrays on the other hand, iter_list is instantiated in the body of a repeat ir, so it can be evaluated several times.

Here are three illustrating examples. In the first example, the following test case pre-evaluates the iter list and stores the result to a temporary list in memory. So the list is only evaluated once, before entry into the loop body, and the log output will be 0, 0, 0.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in [self.usesideeffect(), self.usesideeffect(), self.usesideeffect()]:
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

However, in the next two examples, because the iterator target is not a list literal, it will be evaluated in the loop body. In the second example, iter_list is an ifexp, thus it will be evaluated lazily in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in ([self.usesideeffect(), self.usesideeffect(), self.usesideeffect()] if True else self.otherclause()):
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

In the third example, iter_list is also an ifexp, thus it will only be evaluated in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256[3]

@deploy
def __init__():
    self.x = [0, 0, 0]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.otherclause()):
        self.x[0] += 1
        self.x[1] += 1
        self.x[2] += 1
        log I(i)

@view
def usesideeffect() -> uint256[3]:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a.pop()

is equivalent to:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a[len(a) - 1]
    a.pop()

rather than:

def poc():
    a: DynArray[uint256, 2] = [1, 2]
    s: uint256 = a[1]
    t: uint256 = a.pop()
    a[1] = s + t  # reverts due to oob access

Vyper's sqrt() builtin uses the babylonian method to calculate square roots of decimals. Unfortunately, improper handling of the oscillating final states may lead to sqrt incorrectly returning rounded up results.

the fix is tracked in https://github.com/vyperlang/vyper/pull/4486

Vulnerability Details

Vyper injects the following code to handle calculation of decimal sqrt. x is the input provided by user.

assert x >= 0.0
z: decimal = 0.0

if x == 0.0:
    z = 0.0
else:
    z = x / 2.0 + 0.5
    y: decimal = x

    for i: uint256 in range(256):
        if z == y:
            break
        y = z
        z = (x / z + z) / 2.0

Notably, the terminal condition of the algorithm is either z_cur == z_prev, or the algorithm runs for 256 rounds.

However, for certain inputs, z might actually oscillate between N and N + epsilon, where N ** 2 <= x < (N + epsilon) ** 2. This means that the current behavior does not define whether it will round up or down to the nearest epsilon.

The example snippet here returns 0.9999999999, the rounded up result for sqrt(0.9999999998). This is due to the oscillation ending in N + epsilon instead of N.

@external
def test():
    d: decimal = 0.9999999998
    r: decimal = sqrt(d)    #this will be 0.9999999999

Note that sqrt() diverges from isqrt() here -- isqrt() consistently rounds down, so it is not subject to the same issue.

Impact Details

Since sqrt() can be used for determining boundary conditions, rounding down is preferred. However, since sqrt() is used very rarely in the wild, this advisory has been assigned an impact of low.

Vyper is a Pythonic Smart Contract Language for the EVM. When the Vyper Compiler uses the precompiles EcRecover (0x1) and Identity (0x4), the success flag of the call is not checked. As a consequence an attacker can provide a specific amount of gas to make these calls fail but let the overall execution continue. Then the execution result can be incorrect. Based on EVM's rules, after the failed precompile the remaining code has only 1/64 of the pre-call-gas left (as 63/64 were forwarded and spent). Hence, only fairly simple executions can follow the failed precompile calls. Therefore, we found no significantly impacted real-world contracts. None the less an advisory has been made out of an abundance of caution. There are no actions for users to take.