CVE-2022-25746: Possible cause of this vulnerability in Snapdragon (9th JAN 2023)

Preface: Qualcomm’s current Snapdragon chips for smartphones are also based on Arm technology. The Snapdragon’s central processing unit (CPU) uses the ARM architecture.

Some companies, like Apple, license the ISA from Arm, then design their own physical processor circuits to implement the ISA instructions. Other companies, like Qualcomm historically, also buy the rights to full core designs from Arm, marketed as Cortex. Arm reported $2.7 billion in sales from licensing and royalties in 2021, said CNBC.

For details, see the link – https://www.cnbc.com/2022/09/01/why-arms-lawsuit-against-qualcomm-is-a-big-deal.html

Conceptual baseline: The firmware is first loaded into a predefined memory region and authenticated in the secure world, then the remote processor is reset and starts executing it. These regions of memory should be reserved so that Linux does not map them and make them available exclusively to remote processors and the drivers that load their firmware.

Background: In Snapdragon SoCs, three components are used to provide access control: Virtual Master ID Mapping Table (VMIDMT), External Protection Unit (XPU), and System Memory Management Unit (SMMU). VMIDMT and XPU work together: VMIDMT applies security attributes corresponding to a security domain to transactions (e.g. read/write), while XPU enforces access control policies based on security domains. SMMU maps transactions to security domains and enforces corresponding access control policies.

Vulnerability details: Certain versions of Snapdragon from Qualcomm Inc. contain the following vulnerability:

Memory corruption in kernel due to missing checks when updating the access rights of a memextent mapping. For more information on this design weakness, see the link – https://www.qualcomm.com/company/product-security/bulletins/january-2023-bulletin

My observation: We locked down memextent keyword, so we assumed that design weakness will be ecountered in Type-1 hypervisor (Refer to attached diagram (point 6)).

Reference: Gunyah is a Type-1 hypervisor independent of any
high-level OS kernel, and runs in a higher CPU privilege level. It does
not depend on any lower-privileged OS kernel/code for its core
functionality. This increases its security and can support a much smaller trusted computing base than a Type-2 hypervisor.

But how to exploit this design weakness. There may be an opportunity for an attacker to exploit another vulnerability to trigger this weakness (see below).

CVE-2023-21420 Use of Externally-Controlled Format String vulnerabilities in STST TA

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.