CVE-2023-32058High· 7.5▾ TwilightVyper vulnerable to integer overflow in loop
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.2 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Sep 12.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.9%
Due to missing overflow check for loop variables, by assigning the iterator of a loop to a variable, it is possible to overflow the type of the latter.
In the following example, calling test returns 354, meaning that the variable a did store 354 a value out of bound for the type uint8.
@external
def test() -> uint16:
x:uint8 = 255
a:uint8 = 0
for i in range(x, x+100):
a = i
return convert(a,uint16)
The issue seems to happen only in loops of type for i in range(a, a + N) as in loops of type for i in range(start, stop) and for i in range(stop), the compiler is able to raise a TypeMismatch when trying to overflow the variable.
thanks to @trocher for reporting
patched in 3de1415ee77a9244eb04bdb695e249d3ec9ed868
vyper < 0.3.8Upgrade to a patched release:
vyper 0.3.8Connected by shared product, vendor, weakness, or advisory.
CVE-2020-37288Medium· 3.7Vyper: Return inside for loop more than 1 level deep
CVE-2020-37286Medium· 6.5Vyper 0.1.0b4 before 0.3.0 Memory Corruption via Nested Internal Function Calls
CVE-2020-37287Medium· 5.9Vyper before 0.2.6 Call Stack Corruption via Complex Type Function Arguments
GHSA-vg88-3v92-rjx2MediumVyper: Return inside for loop more than 1 level deep
GHSA-2r3x-4mrv-mcxfMediumVyper: Memory corruption using function calls within tuples / nested calls
GHSA-4v7v-gqf9-ww2gMediumVyper: Call stack corruption when passing complex type containing non-base type members as argument