Out-of-bounds write in the Renesas TSIP TLS 1.3 transcript buffer. In tsipStoreMessage() the capacity check guarding the fixed message bag (MSGBAGSIZE) sets an error code but fails to return, so execution falls through to an XMEMCPY that writes past the end of the buffer once the accumulated TLS 1.3 handshake transcript exceeds MSGBAGSIZE (8 KB), corrupting adjacent heap state and potentially causing a remote denial of service crash. The bag is sized to hold a normal handshake, so this is reached only by an unusually large but valid certificate chain, or by a malicious or man-in-the-middle server sending an oversized handshake message to a client that does not strictly verify the chain. This only affects builds using the Renesas TSIP TLS port (WOLFSSLRENESASTSIPTLS) as a TLS 1.3 client on Renesas MCUs with TSIP hardware enabled, and is rated High within those builds. All other configurations are unaffected.

Buffer overflow in "rcardevinit" due to using due to using untrusted data (rcarimagenumber) as a loop counter before verifying it against RCARMAXBL3XIMAGE. This could lead to a full bypass of secure boot.

Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') vulnerability in Renesas arm-trusted-firmware allows Local Execution of Code. This vulnerability is associated with program files https://github.Com/renesas-rcar/arm-trusted-firmware/blob/rcargen3v2.5/drivers/renesas/common/io/i... https://github.Com/renesas-rcar/arm-trusted-firmware/blob/rcargen3v2.5/drivers/renesas/common/io/iorcar.C .

In line 313 "addrloadedcnt" is checked not to be "CHECKIMAGEAREACNT" (5) or larger, this check does not halt the function. Immediately after (line 317) there will be an overflow in the buffer and the value of "dst" will be written to the area immediately after the buffer, which is "addrloadedcnt". This will allow an attacker to freely control the value of "addrloadedcnt" and thus control the destination of the write immediately after (line 318). The write in line 318 will then be fully controlled by said attacker, with whichever address and whichever value ("len") they desire.

Integer Underflow (Wrap or Wraparound) vulnerability in Renesas arm-trusted-firmware. An integer underflow in image range check calculations could lead to bypassing address restrictions and loading of images to unallowed addresses.

Incorrect Calculation vulnerability in Renesas arm-trusted-firmware allows Local Execution of Code.

When checking whether a new image invades/overlaps with a previously loaded image the code neglects to consider a few cases. that could An attacker to bypass memory range restriction and overwrite an already loaded image partly or completely, which could result in code execution and bypass of secure boot.

During the secure boot, bl2 (the second stage of the bootloader) loops over images defined in the table “bl2memparamsdescs”. For each image, the bl2 reads the image length and destination from the image’s certificate. Because of the way of reading from the image, which base on 32-bit unsigned integer value, it can result to an integer overflow. An attacker can bypass memory range restriction and write data out of buffer bounds, which could result in bypass of secure boot.

Affected git version from c2f286820471ed276c57e603762bd831873e5a17 until (not

An issue was discovered on Renesas RX65 and RX65N devices. With a VCC glitch, an attacker can extract the security ID key from the device. Then, the protected firmware can be extracted.

An issue was discovered on Renesas SmartBond DA14691, DA14695, DA14697, and DA14699 devices. The Nonce used for on-the-fly decryption of flash images is stored in an unsigned header, allowing its value to be modified without invalidating the signature used for secureboot image verification. Because the encryption engine for on-the-fly decryption uses AES in CTR mode without authentication, an attacker-modified Nonce can result in execution of arbitrary code.

An issue was discovered on Renesas SmartBond DA14691, DA14695, DA14697, and DA14699 devices. The bootrom function responsible for validating the Flash Product Header directly uses a user-controllable size value (Length of Flash Config Section) to control a read from the QSPI device into a fixed sized buffer, resulting in a buffer overflow and execution of arbitrary code.