Overview

This article mainly discusses five kernel vulnerabilities in the Snapdragon chipsets and ARM Mali GPU. These vulnerabilities have been reported to CISA KEV (Known Exploited Vulnerabilities Catalog). It is understood that all vulnerabilities have been exploited in the wild.

Currently, the details of the exploit have not been publicly disclosed, and vendors have released security patches and announcements, which include some general information about the underlying vulnerabilities (such as affected products and vulnerability categories). Due to the inability to access the original 0-day exploit code, this article mainly obtains more information about the vulnerabilities by examining the patches to clarify the actual impact of the exploits.

Table 1. Summary of Relevant Vulnerabilities in Technical Analysis

Background

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

MSM implements specific enhancements to the Linux kernel for hardware support unique to Qualcomm: including kernel drivers for micro-devices on the chip, advanced operating system kernel groups, and communication interfaces. A look at the Snapdragon 801 technical brief (PDF) reveals that it is one of many Snapdragon SoC models manufactured by Qualcomm. This specific chipset powers NASA’s Ingenuity helicopter, which landed on Mars on February 18, 2021.

Snapdragon 801 Processor Product Overview

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

Additionally, certain components on the Snapdragon SoC run separate real-time operating systems, requiring dedicated communication interfaces with HLOS (such as AOSP) to offload workflows to the DSP and read results. MSM is also responsible for supporting such communication channels on the HLOS side (such as QMI).

Modern smartphone-level Snapdragon SoC programs are more complex, with more CPU cores, a greater number of dedicated hardware interfaces, higher clock rates, distinctions between 64-bit and 32-bit, and more advanced wireless connectivity infrastructure. Many Android smartphones are based on Snapdragon SoCs, and today’s iPhones use only a standalone cellular modem chip from the Snapdragon series; the following image is a typical schematic of a Snapdragon SoC (820e).

Hexagon Diag Presentation PPT

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

ARM Mali is a GPU core design by Arm Holdings, which licenses it to industry partners for use in hardware products. The list of SoCs embedding Mali GPUs is extensive, including MediaTek, which is Qualcomm’s main competitor in the mobile hardware world. In summary, Mali GPUs and Adreno GPUs are mobile GPU cores, each appearing in about 30% to 40% of Android-based smartphones (iPhones use Apple’s proprietary GPU design).

Snapdragon is not equal to ARM. Specifically, ARM defines the CPU instruction set architecture (ISA) and processor hardware design based on it, while Qualcomm’s licensing only includes the GPU portion. As shown in the example SoC, the 32-bit Krait CPU and 64-bit Snapdragon use Kryo CPU, while the other 8 components on the board are unrelated to ARM (including the Adreno GPU designed and manufactured by Qualcomm itself). Therefore, Adreno GPUs and Mali GPUs have two different and incompatible hardware designs, requiring different operating system kernel drivers, in which vulnerabilities may be found.

After gaining some clarity on the vulnerable targets, let’s take a look at the actual vulnerabilities.

CVE-2023-33063: Use-After-Free in aDSP FastRPC DMA Memory Management

From Qualcomm’s announcement: “Use-after-free in MSM Linux kernel DSP service, memory corruption occurs during remote calls from HLOS to DSP.”

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

The vulnerability exists in the implementation of the FastRPC aDSP device driver code. The patch is too long to display in full here.

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

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

Specifically, the aDSP processor exposes a fastrpc device through a hardware bus, which implements the CPU-DSP communication interface based on DMA hardware technology. The DMA support in the operating system kernel requires mapping and unmapping memory buffers so that data can be mirrored from the hardware device to RAM accessible by the CPU and then back again. During dynamic execution of mapping and unmapping, pointer management of the allocated area may encounter issues, leading to conditions of use-after-free, which is the cause of the vulnerability.

The patch introduces a new variable unsigned int ctx_refs, which saves the context reference count for the fastrpc buffer. This indicates that the fastrpc buffer is released at an inappropriate time while certain code is still using it, leading to a use-after-free (UAF) vulnerability. According to the contents of the patch, it appears that the vulnerability occurs in the unmapping code, thus the patch adds an additional condition to check the value of the new variable ctx_refs.

Example Patch for CVE-2023-33063

This vulnerability is likely opened an attack vector from user mode to kernel through the IOCTL interface, and use-after-free vulnerabilities are generally easy to exploit. This vulnerability in the MSM Linux kernel could be exploited in conjunction with other vulnerabilities to escape the Android application sandbox, thereby elevating the exploit payload permissions. Furthermore, this could serve as a stepping stone to achieving persistent root access.

CVE-2023-33106: Unfiltered Input in Adreno GPU KGSL IOCTL

From Qualcomm’s security announcement: “Memory corruption occurs in graphics when using out-of-bounds pointer offsets during submission of AUX command lists to IOCTL KGSL GPU AUX COMMAND.”

Full Patch Code for CVE-2023-33106

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

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

The patch adds a sanity check for numsyncs, a variable derived from user requests in IOCTL KGSL GPU AUX COMMAND. This variable is later used as an unchecked loop counter in downstream code (kgsl_drawobj.c), leading to memory corruption.

CVE-2023-33107: Integer Overflow in KGSL IOMMU SVM Memory Management

Vendor: Integer overflow or wraparound in Graphics Linux during IOCTL calls when allocating shared virtual memory regions causes memory corruption in Graphics Linux.

Full Patch Code for CVE-2023-33107

This vulnerability is similar to the previous one and is located in the kgsl driver for the Adreno GPU. The patch clearly indicates the underlying vulnerabilities involved: gpuaddr and variable. Additionally, the patch description indicates that the vulnerability is located in the 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). For Android applications to enable this communication, the GPU kernel driver must implement the infrastructure for establishing and managing shared memory regions, reading/writing data, atomic operations, etc., part of which is implemented through the IOCTL interface of the kgsl character device.

Revisiting this vulnerability, it is located in the kgsl iommu.c source module, where the function iommu_addr_in_vm_ranges implements integrity checks on three input parameters related to low-level SVM memory management for the GPU. The memory management unit (MMU) is one of the most complex issues in operating system kernel practice and requires specialized handling; in our case, it is important to know how users can influence these parameters. Here is the invocation of the checks:

Invocation of Error Checks (kgsl_iommu.c)

When a validation error occurs due to integer wraparound, malicious gpuaddr and size parameters will be passed down to downstream code, causing memory corruption (initial guesses indicate this may be through corrupted linked list management). After a long chain of calls within the driver, reaching the code for IOCTL_KGSL_GPUOBJ_IMPORT can be achieved, which has the following parameters:

Definition and Parameters of IOCTL_KGSL_GPUOBJ_IMPORT

This IOCTL command represents a higher-level implementation of the GPU communication protocol for SVM (passing “GPU objects” across processor boundaries).

CVE-2022-22071: Use-After-Free in aDSP Driver Memory Management

According to Qualcomm’s security announcement: “Use-after-free in the Android Automotive OS platform, when releasing process shell memory with IOCTL munmap and initializing the process, a use-after-free issue may exist.”

Full Patch Code for CVE-2022-22071

This vulnerability raises several concerns. First, it was fixed in May 2022, but reported to have been exploited in the wild in October 2023. Typically, the credit for 0-day attacks goes to incident response analysts who discover and capture the attack, while security researchers who discover vulnerabilities do so anonymously. This indicates that the vulnerability may have been exploited on unpatched devices, becoming an N-day vulnerability, or exploited on OEM devices that currently run outdated software and have not been updated. Regardless of which scenario is true, the October attack may be concluded through patch analysis, similar to the workflow I described in this article.

Secondly, the vulnerability target is marked as “Automotive OS Platform Android,” while the patch itself is located in the same adsprpc.c source module seen in CVE-2023-33063. Was it exploited in automotive? Or can the vulnerability only be triggered on automotive platforms, as the vulnerability code clearly affects the entire aDSP driver platform? This contains a wealth of information.

Third, this is the only vulnerability on the list added to the CISA KEV list in October rather than December. CISA does not seem to rely directly on reports from Google TAG and software vendors but seeks evidence of 0-day attacks through other sources.

The implication of the patch is straightforward: certain memory in the adsprpc device driver is still in use, so its subsequent pointers are not released. The is_filemap variable is a “flag indicating mapping used during process initialization,” checked in the unmapping code as follows:

Details of CVE-2022-22071

CVE-2023-4211: Mali GPU IOCTL Handling

ARM Announcement: “The Mali GPU kernel driver allows improper GPU memory handling operations, meaning that local non-privileged users can perform improper GPU memory handling operations to gain access to released memory.”

This is the only vulnerability in the list affecting non-Qualcomm Android devices (for example, devices based on MediaTek SoCs).

When examining the code of the Bifrost GPU kernel driver, there were significant changes between r42p0 and r43p0 (with approximately 10,000 lines of source code differences), making it essential to identify specific vulnerability patches. A quick check of changes in the kbase csf queue register is a good candidate:

Suspected Patch for CVE-2023-4211

Here, the kbase csf queue register function can be accessed via KBASE_IOCTL_CS_QUEUE_REGISTER_ioctl, and it involves additional cleanup of input parameters related to GPU memory management.

Conclusion

This article covers five different vulnerabilities in the Android kernel that have been actively exploited since October. Previously unknown technical details were obtained through security patches and other public sources, and a limited root cause analysis of several vulnerabilities was conducted, primarily inferred from security patches and other public sources, as the original vulnerability code could not be accessed.

The vulnerabilities described in this article can affect over 80% of Android devices, primarily including mobile smartphones, but may also impact smart cars, IoT devices, and wearables.

The impact of the vulnerabilities: they can perform Android application sandbox escape and elevate permissions to execute arbitrary code. Such vulnerabilities are typically exploited in the third stage of a full-chain exploit, after RCE via a browser or similar remote attack medium. Furthermore, these vulnerabilities open a persistent attack surface, which usually requires a third vulnerability to achieve.

Overall, a complete attack chain on modern mobile smartphones (whether based on Android or iPhone, the distinction is minimal) typically requires at least four different vulnerabilities:

1. Remote code execution vulnerability in an application (for example, a vulnerability in the JavaScript engine of a mobile browser).

2. Memory information leakage vulnerability in an application to defeat ASLR.

3. Application sandbox bypass and privilege escalation vulnerabilities.

4. Bootloader or similar level vulnerabilities to bypass secure boot technologies and maintain persistence between device reboots.

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

Reference Links:

https://docs.qualcomm.com/product/publicresources/securitybulletin/december-2023-bulletin.html

https://docs.qualcomm.com/product/publicresources/securitybulletin/october-2023-bulletin.html

https://git.codelinaro.org/clo/la/kernel/msm-5.4

https://developer.arm.com/Arm%20Security%20Center

https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Original Source: Seebug Paper

“Submission Contact: 010-82992251 [email protected]”