In radare2 through 4.0, there is an integer overflow for the variable new_token_size in the function r_asm_massemble at libr/asm/asm.c. Thi…
In radare2 through 4.0, there is an integer overflow for the variable new_token_size in the function r_asm_massemble at libr/asm/asm.c. This integer overflow will result in a Use-After-Free for the buffer tokens, which can be filled with arbitrary malicious data after the free. This allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via crafted input.
The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number.
https://cwe.mitre.org/data/definitions/190.html →Open in CWE collection →This attack forces an integer variable to go out of range. The integer variable is often used as an offset such as size of memory allocation or similarly. The attacker would typically control the value of such variable and try to get it out of range. For instance the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value which can lead to unexpected behavior. At worst the attacker can execute arbitrary code.
https://capec.mitre.org/data/definitions/92.html →Open in CAPEC collection →| Product | Vendor | Status |
|---|---|---|
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | Tracked | |
| radare2 | * | Tracked |