The Texas Instruments OMAP L138 (secure variants) trusted execution environment (TEE) lacks a bounds check on the signature size field in the SK_LOAD 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 SK_LOAD module encrypted with the CEK (obtainable through CVE-2022-25332). This constitutes a full break of the TEE security architecture.

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 SK_LOAD 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 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 SK_LOAD secure kernel routine can be used to recover the Customer Encryption Key (CEK).