Exploring the Impact of 0-Day Exploitation in Qualcomm MSM Linux Kernel and ARM Mali GPU

Overview

This article focuses on five kernel vulnerabilities in Snapdragon chipsets and ARM Mali GPUs. ARM Mali GPU, these vulnerabilities have been reported to CISA KEV (Known Exploited Vulnerabilities Directory). It is understood that all vulnerabilities have been exploited in the wild.

The details of the vulnerability exploitation have not yet been publicly disclosed. Various vendors have issued security patches and bulletins, which include some general information about the underlying vulnerabilities (such as affected products and vulnerability categories). Without access to the original 0-day exploit code, this article focuses on getting more information about the vulnerability by looking at the patch to clarify the actual impact of the exploit.

ID	Vendor	Product	Component	Code target	Bug class	Patch
CVE-2023-33063	Qualcomm	MSM kernel	DSP Services	aDSP FastRPC DMA memory management	Use-after-free	msm-5.15 , msm-4.14
CVE-2023-33106	Qualcomm	MSM kernel	Adreno GPU driver	KGSL high-level IOCTL logic	Memory Corruption due to Unsanitized Input	msm-4.19
CVE-2023-33107	Qualcomm	MSM kernel	Adreno GPU driver	KGSL IOMMU SVM memory management	Memory Corruption due to Integer Overflow	msm-4.19
CVE-2022-22071	Qualcomm	MSM kernel	DSP Services	aDSP driver memory management	Use-after-free	msm-5.4
CVE-2023-4211	ARM	Mali GPU	Kernel software driver	IOCTL management of driver memory	Memory corruption due to Unsanitized Input(?)	n/a

Background

Qualcomm chipset smartphones use a customized version of the Linux kernel called MSM, and most of the vulnerabilities discussed in this article are based on this vulnerable kernel.

MSM's specific addition to the Linux kernel implements hardware support for Qualcomm-specific features: including kernel drivers for handling tiny devices on the chip, a high-level operating system kernel set, and communications interfaces. Check out the Snapdragon 801 technical briefing (PDF) and discover that it's one of many Snapdragon SoC models made by Qualcomm. This specific chipset powers NASA's Ingenuity helicopter, which landed on Mars on February 18, 2021.

The SoC (system on chip) has only nine components on board: in addition to the CPU, there is an Adreno GPU, a digital signal processor (DSP), an integrated wireless connectivity chip, sensors, cameras, satellite support, a display and a multimedia chip. Each component is an independent hardware device and requires a dedicated kernel driver to support it in the operating system.

In addition, some components on the Snapdragon SoC run a separate real-time operating system, which requires a dedicated communication interface with HLOS (such as AOSP) to offload the workflow to the DSP and read the results. MSM is also responsible for supporting such communication channels (such as QMI ) on the HLOS side .

Modern smartphone-level Snapdragon SoC programs are more complex, with more CPU cores, the number of dedicated hardware interfaces, higher clock rates, 64-bit and 32-bit differences, more developed wireless connection infrastructure, etc. Many Android smartphones are based on Snapdragon SoCs, and today's iPhones only use a separate cellular modem chip from the Snapdragon series. The figure below is a schematic diagram of a typical Snapdragon SoC (820e)

Now that we know what Qualcomm MSM is, let’s look at the ARM Mali target (CVE-2023-4211).

ARM Mali is Arm Holdings' GPU core design , which it licenses to industry partners for use in hardware products. The list of SoCs embedding Mali GPUs is long and includes MediaTek , Qualcomm's main competitor in the mobile hardware world. All told, the Mali GPU and Adreno GPU are mobile GPU cores, each found in about 30% to 40% of Android-based smartphones (the iPhone uses Apple's own proprietary GPU design).

Snapdragon is not equal to ARM. Specifically, ARM defines the CPU instruction set architecture (ISA) and the processor hardware design based on it, while the licensing rights obtained by Qualcomm only include the GPU part. As shown in the sample SoC, the 32-bit Krait CPU and 64-bit Snapdragon use the Kryo CPU, and the remaining 8 components on the motherboard have nothing to do with ARM (including the Adreno GPU designed and produced by Qualcomm itself). As a result, Adreno GPUs and Mali GPUs have two different and incompatible hardware designs that require different operating system kernel drivers, and vulnerabilities may be found in these drivers.

Now that you have some clarity on what's vulnerable, let's take a look at the actual vulnerabilities.

CVE-2023-33063: Use-after-free in aDSP FastRPC DMA memory management

Announcement from Qualcomm: "Reuse-after-free in the MSM Linux kernel DSP service causes memory corruption in the DSP service during a remote call made by HLOS to the DSP."

Interestingly, this vulnerability was not added to the CISA KEV list until December, while Qualcomm notified the 0-day exploit in October.

The vulnerability exists in the aDSP device driver code that implements FastRPC. The patch is too long to be shown in full here.

Modern Snapdragon SoCs have multiple DSP processors dedicated to different categories of computing tasks. The aDSP (application DSP) is responsible for audio and sensor input processing (sensor processing has been offloaded to a dedicated sDSP core), while the mDSP runs the cellular modem code and the cDSP runs the AI calculations. The architecture of all DSP cores is based on Hexagon , Qualcomm's proprietary processor architecture, which has a unique assembly coding mode and is one of the few successful VLIW ISA designs.

From the perspective of hardware architecture, the DSP core is independent and managed by a separate operating system, and the CPU runs HLOS (such as the Android open source project or its OEM customized version). The DSP runs a real-time operating system, which in modern Qualcomm chipsets is QuRT. The CPU and DSP cores are isolated from each other, therefore, they must communicate through some interface, implemented by the MSM core on the CPU/HLOS side, the RPC protocol usually encodes the high-level aspects of the communication interface. The adsprpc.c source module where the vulnerability resides implements this code.

Specifically, the aDSP processor exposes a fastrpc device through the hardware bus, which implements the CPU-DSP communication interface based on DMA hardware technology. DMA support in the operating system kernel requires memory buffers to be mapped and unmapped so that data can be mirrored from the hardware device to CPU-accessible RAM and back again. When mapping and unmapping are performed dynamically, problems may arise in pointer management of allocated areas, leading to a use-after-free condition, which is the cause of the vulnerability.

The patch introduces a new variable unsigned int ctx_refsthat holds the number of context references to the fastrpc buffer. This indicates that in the affected code, the fastrpc buffer was released at an inappropriate time, but was still used by some code, resulting in a use-after-free (UAF) vulnerability. According to the content of the patch, the vulnerability may have occurred in the unmapping code, so the patch added an additional condition to check ctx_refsthe value of the new variable.

This vulnerability is likely to open an attack vector from user mode to the kernel through the IOCTL interface. The use-after-free vulnerability is easily exploited in most cases. This vulnerability in the MSM Linux kernel may be exploited on Qualcomm-based phones in conjunction with other vulnerabilities to escape the Android application sandbox and thereby elevate vulnerability payload privileges. Additionally, this could be a stepping stone to achieving persistent root.

CVE-2023-33106: Unsanitized input in Adreno GPU KGSL IOCTL

From Qualcomm Security Advisory: "Using out-of-range pointer offsets in graphics, IOCTL KGSL GPU AUX COMMANDmemory corruption occurs when submitting an AUX command that submits a synchronization point list."

Similar to DSP microdevices on mobile SoCs, GPU microdevices require dedicated operating system kernel support, and for Snapdragon's Adreno GPUs, this support is implemented in KGSL's kernel driver. One of the source modules implementing this driver in the MSM Linux kernel is located at drivers/gpu/msm/kgsl.c.

To further narrow down the scope of the affected code, we traced it to the IOCTL processing logic. IOCTL is a common mechanism for communication between the operating system user layer and the kernel, used in all major operating systems. The actual communication is achieved by sending module-specific commands and data through interfaces exposed by the kernel. For example, on Linux, ioctl()a system call is used, with a specific command ID and parameters, and the kernel forwards these parameters to the corresponding loadable kernel module, where the call parameters are parsed. The implementation of IOCTL handling is module-specific, and kernel modules may incorrectly handle data provided in IOCTL parameters, which may lead to exploitable memory corruption and logic vulnerabilities.

The patch adds a sanity check for numsyncs on variables coming from the user in the IOCTL request IOCTL KGSL GPU AUX COMMAND. This variable is later used as an unchecked loop counter in downstream code (kgsl_drawobj.c), causing memory corruption.

CVE-2023-33107: Integer overflow in KGSL IOMMU SVM memory management

Vendor: Integer overflow or wraparound in Graphics Linux Memory corruption in Graphics Linux occurs when allocating a shared virtual memory area during an IOCTL call.

This vulnerability is similar to the previous one and is located in the kgsl driver of Adreno GPU. It is obvious from the patch that the vulnerability involves the underlying layer: gpuaddr and variables. Additionally, the patch description indicates that the vulnerability is in IOCTL handling.

GPU computing is independent of the CPU and can communicate with the CPU through a feature called SVM (Shared Virtual Memory) introduced in OpenCL 2.0. SVM shared memory regions can be accessed from Android applications (on the CPU) and graphics shaders (on the GPU). In order for Android applications to enable this communication, the GPU kernel driver must implement the infrastructure for establishing and managing shared memory regions, reading and writing data, atomic operations, etc. Part of the communication infrastructure is implemented through the IOCTL interface of the kgsl character device.

Looking at the vulnerability again, located kgsl iommu.cin the source module, the function iommu_addr_in_vm_rangesimplements an integrity check on three input parameters related to the GPU's low-level SVM memory management. Memory management unit (MMU) internals are one of the most complex issues in operating system kernel practice and require specialized treatment. As far as we are concerned, it is important to know how the user can influence these parameters. Here is the call to the checker:

When a checksum error occurs due to integer wraparound, malicious gpuaddr and size parameters are passed to downstream code and cause memory corruption (initial guess is through corrupted linked list management). After going through a long string of calls inside the driver, you can use the code that IOCTL_KGSL_GPUOBJ_IMPORTarrives kgsl_iommu_set_svm_regionat the call with the following parameters:

This IOCTL command represents a higher-level implementation of SVM's GPU communication protocol (passing "GPU objects" across processor boundaries).

CVE-2022-22071: Restart after free in aDSP driver memory management

According to Qualcomm's security advisory: "In the Android automotive operating system platform, when using the IOCTL munmap call to release the process shell memory and perform process initialization, there may be a restart after release problem."

This vulnerability raises several concerns. First, the vulnerability was fixed in May 2022, but exploits in the wild were reported in October 2023. Typically, credit for zero-day attacks goes to the incident response analyst who discovered and captured the attack, while the security researcher who discovered the vulnerability remains anonymous. This suggests that the vulnerability could be exploited as an N-day vulnerability on unpatched devices, or on OEM devices that currently offer outdated software and are not updated. Regardless of the above scenario, the October attack was likely concluded through patch analysis, similar to the workflow I describe in this article.

Second, the vulnerability target is tagged "Automotive OS Platform Android" and the patch itself is located in the same adsprpc.c source module seen in CVE-2023-33063. Is it being exploited in cars? Or is the vulnerability only triggerable on automotive platforms because the vulnerable code apparently affects the entire platform of the aDSP driver? There is a lot of information in this.

Third, this is the only vulnerability on the list that was added to the CISA KEV list in October rather than December. CISA does not appear to rely directly on Google TAG and software vendor reports, but instead seeks to establish evidence of zero-day attacks through other sources.

The implication of this patch is simple: some memory is still in use by the adsprpc device driver, so the pointers behind it will not be freed. is filemapThe variable is a "flag indicating the mapping used in process initialization", which is checked in the unmapping code like this:

CVE-2023-4211: Mali GPU IOCTL handling

ARM advisory : "The Mali GPU kernel driver allows improper GPU memory handling operations, whereby a local unprivileged user can perform improper GPU memory handling operations to gain access to freed memory."

This is the only vulnerability in a series that affects non-Qualcomm Android devices, such as those based on MediaTek SoCs.

When looking at the code for the Bifrost GPU kernel driver, a large number of code changes occurred between r42p0 and r43p0 (approximately 10,000 lines of source code difference), making it important to identify patches for specific vulnerabilities. A quick check of the changes in the kbase csf queue register is a good candidate:

Here, kbase csf queue registerthe function is KBASE_IOCTL_CS_QUEUE_REGISTER_ioctl accessible through calls, and it involves additional sanitization of input parameters related to GPU memory management.

Conclusion

This note covers 5 different vulnerabilities in the Android kernel that were actually exploited in October. Previously unknown technical details were obtained through security patches and other public sources, and a limited root cause analysis was performed on several of these vulnerabilities. This analysis was mainly inferred from security patches and other public sources without access to the original vulnerability code.

The vulnerabilities described in this article can attack more than 80% of Android devices, mainly including mobile smartphones, and may also affect smart cars, the Internet of Things, and wearable devices.

Impact of the vulnerabilities: They can escape the Android application sandbox and escalate privileges to execute arbitrary code. Such vulnerabilities are typically exploited during the third stage of a full-chain exploit, following RCE via a browser, or similar remote attack vectors. Additionally, these vulnerabilities open up a persistent attack surface, which often requires a third vulnerability to achieve.

Overall, a complete attack chain on a modern mobile smartphone (based on Android or iPhone, not much difference) usually requires at least four different vulnerabilities:

Remote code execution vulnerabilities in applications (such as JavaScript engine vulnerabilities in mobile browsers).

Memory information disclosure vulnerability in applications to defeat ASLR.

Application sandbox bypass and privilege escalation vulnerabilities.

A bootloader or similar level vulnerability used to bypass secure boot technology and persist across device reboots.

The issues covered in this article represent common examples of stage three vulnerabilities in the complete attack chain. In more specific cases (such as attacking a hardened system or using a weaker vulnerability), the third stage of the complete attack chain may need to be further split into two separate vulnerabilities.