The AES implementation in the Texas Instruments OMAP L138 (secure variants), present in mask ROM, suffers from a timing side channel which can be exploited by an adversary with non-secure supervisor privileges by managing cache contents and collecting timing information for different ciphertext inputs. Using this side channel, the SKLOAD secure kernel routine can be used to recover the Customer Encryption Key (CEK).

The Texas Instruments OMAP L138 (secure variants) trusted execution environment (TEE) performs an RSA check implemented in mask ROM when loading a module through the SKLOAD routine. However, only the module header authenticity is validated. An adversary can re-use any correctly signed header and append a forged payload, to be encrypted using the CEK (obtainable through CVE-2022-25332) in order to obtain arbitrary code execution in secure context. This constitutes a full break of the TEE security architecture.

The Texas Instruments OMAP L138 (secure variants) trusted execution environment (TEE) lacks a bounds check on the signature size field in the SKLOAD module loading routine, present in mask ROM. A module with a sufficiently large signature field causes a stack overflow, affecting secure kernel data pages. This can be leveraged to obtain arbitrary code execution in secure supervisor context by overwriting a SHA256 function pointer in the secure kernel data area when loading a forged, unsigned SKLOAD module encrypted with the CEK (obtainable through CVE-2022-25332). This constitutes a full break of the TEE security architecture.