Pwn2Own2020：高通骁龙的DSP芯片漏洞挖掘与利用研究

0x01 基本介绍

Snapdragon是一套由高通技术公司设计和销售的用于移动设备的片上系统（SoC）半导体产品。单个SoC可能包括多个CPU内核，一个Adreno图形处理单元（GPU），一个Snapdragon无线调制解调器，一个六边形数字信号处理器（DSP），高通光谱图像信号处理器（ISP）和其他硬件。

Snapdragon产品的不同之处在于它是可扩展的CPU，GPU和DSP处理器的计算资源。最低层可能仅包含一个Hexagon DSP，而高级层最多包含四个专用于特定用例的Hexagon DSP处理器。例如，嵌入在诸如Pixel 4，Samsung S10，Xiaomi Mi 9，LG G8和OnePlus 7等手机中的Snapdragon 855（SM8150）SoC包括一个Kryo CPU，一个Adreno 640和四个独立的DSP，每个模块都专用于特定的应用空间：传感器（sDSP），调制解调器（mDSP），音频（aDSP）和计算（cDSP）。

在此文章中，我们研究了两种DSP：

· cDSP，旨在执行计算密集型任务，例如图像处理，计算机视觉，与神经网络相关的计算以及视频流。

· aDSP，旨在用于音频和语音数据的低功耗处理。

就当前的研究而言，我们将cDSP和aDSP视为一个处理单元（DSP），我们发现的安全性问题对两者都适用。

1.CPU与DSP之间的通讯

FastRPC是高通专有的远程过程调用（RPC）机制，用于启用CPU和DSP之间的远程函数调用。FastRPC框架是一种典型的代理模式。

图1： FastRPC流程。

在图1中，你可以看到FastRPC组件的交互：

（1）用户模式进程（客户端）启动远程调用。例如，一个Android应用程序以其本机代码调用stub函数之一。

（2）stub是自动生成的代码，它将函数调用转换为RPC消息。通常，将stub代码编译为单独的本机库，然后将其与客户端链接。stub代码使用libadsprpc.so和libcdsprpc.so库通过相关的ioctl在应用程序处理器（AP）上调用DSP RPC驱动程序（/dev/adsprpc-smd或/dev/cdsprpc-smd）。

（3）DSP RPC内核驱动程序接收远程消息调用，通过共享内存驱动器（SMD）通道将排队的消息发送到DSP上的DSP RPC框架，然后等待响应。

（4）DSP RPC框架从队列中删除消息，然后将其分派以供skeleton动态库处理。

（5）skel是一个自动生成的库，用于解组参数并调用目标方法的实现。

（6）目标方法（对象）是由高通或OEM提供的逻辑，旨在在DSP上运行。

2.在DSP上运行自己的代码

出于安全原因，DSP已获得OEM和少数第三方软件供应商的许可进行编程。DSP上运行的代码是由高通公司签名的。常规的Android应用程序无权在DSP上执行自己的代码。Snapdragon 855和865 SoC除外，其中Qualcomm被允许在cDSP上执行低权限无签名的动态共享对象。

需要注意的是，Google通过SELinux策略强制保护Pixel设备，以防止第三方应用程序和DSP RPC驱动程序的adb shell访问。

公开可用的Hexagon SDK负责将DSP对象的C / C ++源代码编译为适用于在DSP上执行的Hexagon（QDSP6）字节码。Stub和Skel代码是根据开发人员准备的接口定义语言（IDL）模块自动生成的。Qualcomm IDL用于定义跨内存保护和处理器边界的接口。IDL仅公开该对象的函数，而不公开其驻留的位置或实现该对象的编程语言。

Android应用程序开发人员能够实现其针对DSP的自定义库，但无法完全执行，Android应用程序只能自由调用预构建的DSP库。

3.DSP管理分析

QuRT是管理Hexagon DSP的高通专有多线程实时操作系统（RTOS）。高通公司的安全可执行环境（QSEE）信任QuRT的完整性。QuRT可执行二进制文件（与aDSP和cDSP分开）经过签名并以与Qualcomm设备上任何其他受信任的应用程序相同的方式拆分为多个文件。它的默认位置是/vendor/firmware目录。

对于每个启动远程调用的Android进程，QuRT都会在DSP上创建一个单独的进程。当生成用户进程时，特殊的Shell进程（/vendor/dsp/fastrpc_shell_0用于aDSP、/vendor/dsp/fastrpc_shell_3用于cDSP）将加载到DSP上。shell负责skeleton和对象库的调用。此外，它实现了DSP RPC框架，该框架提供了skel和对象库可能需要的API。

DSP软件体系结构提供了不同的保护域（PD），以确保内核软件的稳定性。DSP中有三个保护域：

· 内核–可以访问所有PD的所有内存。

· guset操作系统–可以访问其自己的PD的内存，用户PD的内存以及某些系统寄存器。

· 用户–仅可以访问其自己的PD的内存。

无签名的动态共享对象在Unsigned PD内运行，这是用户PD在访问基础DSP驱动程序和线程优先级时受到限制的对象。Unsigned PD设计为仅支持通用计算应用程序。

对象库以及FastRPC Shell在User PD中运行。

4.从FastRPC流中跳过stub代码

libadsprpc.so和libcdsprpc.so库负责与DSP RPC驱动程序进行通信。这些库导出了两个值得研究的函数：

· int remote_handle_open(const char* name, remote_handle *ph)。此函数在AP上的调用者进程和DSP上的新FastRPC Shell进程之间打开一个远程会话。该会话用于与指示为第一个参数的框架库进行通信。

· int remote_handle_invoke(remote_handle h, uint32_t scalars, remote_arg *pra)。此函数能够调用框架库的导出方法。会话处理程序应指示为第一个参数。

使用这两个函数，客户端可以执行在任何skeleton库中实现的DSP方法，高通或OEM提供的stub代码可以从链中跳过。

图2：直接调用DSP。

让我们看一下该remote_handle_invoke函数的第二个和第三个参数，它们对目标方法及其参数进行了编码。

scalars 是包含以下元数据信息的单词：

· 方法索引和属性（最高字节，0xFF000000掩码）。

· 输入参数的数量（0x00FF0000掩码）。

· 输出参数的数量（0x0000FF00掩码）。

· 输入和输出句柄的数量（0x000000FF掩码，输入的四位和输出的四位）。在现在的移动设备中，如果此字节不等于零，则DSP调用将失败。

pra是指向remote_arg目标方法的参数（条目）数组的指针。参数的顺序如下：输入参数，输出参数，输入句柄和输出句柄。

如你所见，每个输入和输出参数都转换为通用remote_buf条目。

应该注意的是，如果准备的remote_arg数组条目多于目标方法所需的数组条目，则skeleton库只会忽略多余的参数。

scalars和pra参数传送是通过DSP RPC驱动程序和DSP RPC框架，并且被用作由skeleton库提供的invoke函数的第一个和第二参数。例如，libfastcvadsp_skel.so库提供了fastcvadsp_skel_invoke  invoke函数。invoke函数仅负责按索引调用适当的skel方法。每个skel方法本身都会验证收到的远程参数，将remote_bufs解码为常规类型，然后调用object方法。

如你所见，要从skel库中调用方法，只需要知道其索引并通过remote_buf结构包装每个参数即可。我们不必提供调用函数的名称，其参数的类型和数量来执行调用的事实，使得skeleton库成为非常方便的模糊测试目标。

0x02 对Hexagon库的模糊测试

1.降级漏洞

高通公司已经在Android手机上预先安装了许多skeleton库。它们中的绝大多数是专用的。但是，有一些开源示例，例如libdspCV_skel.so和libhexagon_nn_skel.so。

几乎可以在所有Android设备上找到许多skeleton库，例如libfastcvadsp_skel.so和libscveBlobDescriptor_skel.so。但是，像libVC1DecDsp_skel.so和libsysmon_cdsp_skel.so这样的库仅在现代Snapdragon SoC上提供。

有些库是由OEM实施的，仅在特定供应商的设备上使用。例如，libedge_smooth_skel.so可以在Samsung S7 Edge上找到，libdepthmap_skel.so可以在OnePlus 6T设备上找到。

一般来说，所有的skel库位于无论是在/dsp或/vendor/dsp或/vendor/lib/rfsa/adsp目录。默认情况下，该remote_handle_open函数将精确扫描这些路径。此外，还有一个环境变量ADSP_LIBRARY_PATH，可以在其中添加新的搜索路径。

如前所述，所有DSP库均已签名且无法修补。但是，任何Android应用程序都可以在其资产中携带一个由Qualcomm签名的库，将其提取到应用程序的数据目录中，将路径添加到的开头ADSP_LIBRARY_PATH，然后打开一个远程会话。因为库签名正确，所以库已成功加载到DSP上。

没有加载skeleton库的版本检查为在DSP上运行一个存在1 day漏洞的旧skel库提供了可能性。即使设备上已经存在更新的框架库，也可以仅通过指示其在ADSP_LIBRARY_PATH原始文件路径之前的位置来加载该库的旧版本。这样，攻击者可以轻松绕过任何DSP补丁。此外，通过分析DSP软件补丁，攻击者可以在库中找到一个内部固定的漏洞，然后通过加载未修补的版本来利用它。

由于缺少该设备允许的已批准/拒绝的skeleton库列表，因此可以在其他设备（例如Samsung）上运行针对一个设备（例如Sony Xperia）的库。这意味着在一个OEM库中发现的漏洞会危害所有基于Qualcomm的Android设备。

2.基于反馈的Hexagon库模糊测试

DSP库是专有的Hexagon ELF。检测Hexagon可执行文件的最简单方法是使用QEMU。在2019年底，QEMU中才添加了对Hexagon指令集的支持。我们修复了许多错误，以便能够在QEMU仿真器的用户模式下运行真实的DSP库。

AFL与QEMU组合用于在Ubuntu PC上模糊框架和对象DSP库。

为了在模拟器上执行库代码，我们准备了一个简单的程序（Hexagon ELF二进制文件），该程序负责执行以下操作：

（1）将作为第一个命令行参数接收的数据文件解析为scalars字和remote_arg数组。

（2）dlopen在第二个命令行参数中指定的框架库。该库可能依赖于其他skeleton库和对象库。例如，libfastcvadsp_skel.so依赖于libapps_mem_heap.so，libdspCV_skel.so和libfastcvadsp.so。所有这些库都可以从固件中提取，也可以从真实设备中提取。

（3）通过提供scalars的地址和指向remote_arg数组的指针作为参数来调用函数的地址。例如，fastcvadsp_skel_invoke是模糊测试libfastcvadsp_skel.so库的起点。

我们在程序中使用了以下输入文件格式：

（1）scalars值（4个字节）。在图3所示的示例中，scalars等于0x08020200，这意味着可以通过提供两个输入和两个输出参数来调用方法编号8。

（2）输入参数的大小（每个参数4个字节）：0x10和0x20。

（3）输出参数的大小（每个参数4个字节）：0x80200和0x1000。

（4）输入参数的值。在此示例中，第一个参数的值为0x10字节的0x11，第二个参数的值为0x20字节的0x22。

图3：用于Fuzzing DSP库的输入数据文件。

对于每个输出参数，我们分配指定大小的内存，并用值0x1F填充它。

大多数skeleton库广泛使用DSP框架和系统调用。我们的简单程序无法处理此类请求。因此，我们必须在执行其余代码之前将QuRT加载到QEMU仿真器上。最简单的方法不是使用真正的QuRT OS，而是使用其“精简版” runelf.pbn，该版本已被高通公司采用，可以在Hexagon模拟器上执行并包含在Hexagon SDK中。

AFL输入数据种子文件并触发runelf.pbn在qemu仿真器上运行。QuRT加载准备好的ELF二进制文件，然后调用目标框架库。执行完测试用例后，QEMU将代码覆盖率返回给AFL。

图4： DSP库模糊测试方案。

在我们选择进行模糊处理的所有DSP库中都发现了崩溃，仅在libfastcvadsp_skel.so库中就检测到数百个崩溃。

有趣的是，大多数问题是在框架库中发现的，而并非在对象库中发现的。这意味着Hexagon SDK中存在大量易受攻击的代码。

3.自动生成的代码

让我们看一下开源hexagon_nn库，它是Hexagon SDK 3.5.1的一部分，该库导出了许多与神经网络相关的计算函数。

Hexagon SDK在库编译时自动生成hexagon_nn_stub.cstub和hexagon_nn_skel.c stub模型。通过手动检查模块，可以轻松检测到某些安全问题。我们将仅分析其中的两个。

封装传递字符串（*char **）参数

int hexagon_nn_op_name_to_id(const char* name, unsigned int* node_id)函数需要一个输入（name）和一个输出（node_id）参数。SDK生成以下stub代码来封装传递这两个参数：

我们可以看到，除了现有的两个参数外，第三个remote_arg条目是在_pra数组的开头创建的。此特殊_pra[0]参数保存name字符串的长度。

将name本身保存在第二remote_arg条目（_praIn[0]），它的长度会再次存储，但这次是在_praIn[0].buf.nLen中。

skel代码提取这两个长度，并将它们作为signed int值进行比较。攻击者可以忽略stub代码，并在第一个remote_arg条目中写入一个负值（大于或等于0x80000000），从而绕过此验证。然后，该伪长度用作内存偏移量，并导致崩溃（从堆边界溢出）。

为所有需要字符串参数的对象函数生成相同的代码。

封装传递缓冲区

让我们看一下int hexagon_nn_snpprint(hexagon_nn_nn_id id, unsigned char* buf, int bufLen)函数，它需要一个缓冲区，并且将缓冲区的长度作为参数，缓冲区用于输入和输出数据。因此，它在stub代码中分为两个单独的缓冲区（输入和输出缓冲区）。同样，两个缓冲区（_in1Len和_rout1Len）的长度都存储在附加remote_arg数组（_pra[0]）中。

skel函数在调用对象函数之前将输入缓冲区复制（使用_MEMMOVEIF宏）到输出缓冲区，要复制的数据大小是remote_arg数组（_pra[0]）中保存的输入缓冲区的长度。

攻击者要控制此值。通过使用输入缓冲区的负长度，可以简单地绕过所有验证检查。

在检查缓冲区边界时将类型强制转换为signed int类型是导致堆溢出漏洞的原因。

总而言之，自动生成的代码会将漏洞利用注入到使用Hexagon SDK的Qualcomm，OEM和所有其他第三方开发人员的库中。由于SDK中存在严重漏洞，因此预先安装在Android智能手机上的数十个DSP skeleton库很容易受到攻击。

0x03 SDP漏洞利用与分析

1.利用DSP漏洞

让我们看一下在专有DSP框架库中发现的许多漏洞之一，并尝试寻找“read-what-where”和“write-what-where”原语。

在大多数Android设备上都可以找到libfastcvadsp_skel.so库。在下面的示例中，我们使用从索尼Xperia XZ Premium设备中提取的版本1.7.1的库。恶意的Android应用程序可以通过为remote_handle_invoke函数提供在libfastcvadsp_skel.so库中特制的参数来导致库崩溃。图5中的数据文件显示了此类设计的参数示例。

图5：导致libfastcvadsp_skel.so崩溃的数据文件

如你所见，0x3F方法被调用并提供一个输入和三个输出参数。输入参数的内容以字节0x14开头，并包含以下主要字段：

· 红色0x02显示要读取的半个字（大小）。

· 黄色0x44332211显示了要读取的内容（源）。该值是相对于DSP堆中第一个输出参数的开头的偏移量。使用此偏移量，我们控制读取的起始地址。偏移量可以是我们想要的，甚至可以是负数。

· 青色0x04显示读取位置（目的地）。该值也是偏移量。

崩溃是由于源地址不正确引起的。

图6：crash dump调试。

下面是用于读取原语的POC代码。

输入参数始终位于输出参数之后的DSP堆中。因此，在编写原语时，我们需要根据第一个输出参数的长度来移位源地址（所有其他参数均为空）。

攻击者可以操纵源偏移量和目标偏移量，以在DSP进程（用户PD）的地址空间中进行读取和写入。第一个输出参数与内存中libfastcvadsp_skel.so库之间的偏移量是一个恒定值。很容易在skel或对象库的数据段中找到一个指针来触发调用。出于安全原因，我们不会发布DSP中其余的POC。

2.DSP用户域研究

在对Qualcomm DSP中的skeleton库和对象库进行安全研究期间，我们发现了两个全局安全问题：

· 缺乏DSP库的版本控制。这允许恶意Android应用程序执行降级攻击并在DSP上运行易受攻击的库。

· Hexagon SDK中的问题在使用Qualcomm芯片的移动供应商的代码中导致了数百个隐藏的漏洞。由于Hexagon SDK中的问题，几乎所有嵌入在基于Snapdragon的智能手机中的所有DSP skeleton库都容易受到攻击。

我们向高通公司报告了数十个DSP库中约400个不同的崩溃，其中包括：

· libfastcvadsp_skel.so

· libdepthmap_skel.so

· libscveT2T_skel.so

· libscveBlobDescriptor_skel.so

· libVC1DecDsp_skel.so

· libcamera_nn_skel.so

· libscveCleverCapture_skel.so

· libscveTextReco_skel.so

· libhexagon_nn_skel.so

· libadsp_fd_skel.so

· libqvr_adsp_driver_skel.so

· libscveFaceRecognition_skel.so

· libthread_blur_skel.so

为了演示，我们利用了其中一个发现的漏洞，并获得了在基于Snapdragon的设备（包括三星，Pixel，LG，小米，OnePlus，HTC和Sony手机）的DSP上执行未签名代码的能力。

可以访问DSP用户域的Android应用程序具有以下可能性：

· 触发DSP内核崩溃，然后重新启动移动设备。

· 隐藏恶意代码，防病毒软件不会扫描Hexagon指令集。

· cDSP负责预处理来自摄像头传感器的流视频，攻击者可以接管此流程。

· 访问DSP内核驱动程序。驱动程序中的漏洞可能会将应用程序的权限扩展到guest OS或DSP内核的权限。

3.DSP驱动器

QuRT OS实现了QuRT驱动程序调用（QDI）的设备驱动程序模型。无法从Android API访问QDI。与POSIX一样，QDI设备驱动程序以比请求驱动程序服务的用户代码更高的特权进行操作。QDI提供了一个简单的驱动程序调用API，该API隐藏了与特权模式关联的所有实现细节。

该库是Hexagon SDK的一部分，包含QDI基础结构。FastRPC Shell与libqurt.a库静态链接。

在QuRT可执行二进制文件中可以找到数十个QDI驱动程序。他们通常被命名为/dev/..，/qdi/..，/power/..，/drv/..，/adsp/..或/qos/..。该int qurt_qdi_open(const char* drv)函数可用于访问QDI驱动程序。返回一个小的整数设备句柄。这与POSIX文件描述符直接并行执行。

QDI仅提供一个宏，它是必需的用户可见的API。该qurt_qdi_handle_invoke宏负责所有常规驱动程序操作。实际上，qurt_qdi_open只是该宏的一种特殊情况。这些是宏参数：

（1）QDI句柄或预定义常数值之一。

（2）定义请求操作的方法号。在SDK头文件中，我们看到：

   · 方法1和2保留用于名称注册和名称查找。

   · 3 – 31保留用于在打开的句柄上进行POSIX类型的操作。

   · QDI基础结构保留了32 – 127。

   · 保留128 – 255供使用自动生成的方法（例如IDL可能生成的方法）。

   · 私有方法编号为256和更高。

（3）零到九个可选的32位参数。

qrt\u qdi\u handle\u invoke宏调用相关的设备驱动程序调用函数，该函数实现主驱动程序逻辑，并提供指定的方法编号和可选参数。

这是从用户PD代码调用QDI驱动程序的示例：

QDI驱动程序使用int qurt_qdi_devname_register(const char *name, qurt_qdi_obj_t *opener)API函数在QuRT中注册自己，驱动程序提供其名称和指向opener对象的指针作为参数。

opener对象的第一个字段是驱动程序调用函数。QuRT调用此函数来处理来自用户PD或另一个驱动程序的驱动程序请求，并提供以下参数：

· QDI句柄，代表发送了QDI请求的客户端。

· 发出此QDI请求的opener对象。

· 调用者提供的QDI方法。

· 调用者提供的九个可选参数。

通常，驱动程序调用函数是QDI方法ID的切换操作符。每种方法可以使用与提供的参数数量不同的参数。参数类型为qurt_qdi_arg_t。

请注意，驱动程序调用函数是基于模糊测试的漏洞研究的一个很好的目标，因为方法是由ID标识的，而不是由名称标识的，调用方不需要知道调用驱动程序方法的参数的确切数目及其实际类型。

0x04 QDI驱动程序漏洞挖掘与利用

1.QDI驱动程序基于反馈的模糊测试

为了在Ubuntu PC上Fuzzing QDI驱动程序，我们使用了QEMU Hexagon和AFL组合来Fuzzing DSP库。但是，我们实现的不是skel_loader程序，而是另一个Hexagon ELF二进制程序qdi_exec，它负责执行这些操作：

（1）将作为第一个命令行参数接收的数据文件解析为QDI方法ID和驱动程序调用函数的九个参数的数组。

（2）通过第二个命令行参数中指定的地址调用驱动程序调用函数，并提供QDI方法ID和从数据文件中解码的参数。

我们为qdi_exec程序使用了以下输入文件格式：

· Header（4个字节）。它包含三个字段值：

   · QDI方法ID（10个低位）。在图7的示例中，它是0x01。

   · 参数数量（4位）。在该示例中，仅使用了一个参数。其余八个自变量被认为是零。

   · 参数类型的掩码（9位）。如前所述，每个参数都是数字或指向缓冲区的指针。在掩码中，每个自变量用一位表示。零值表示该参数是一个数字，正值表示该参数是一个缓冲区。

· 缓冲区参数的大小（每个参数4个字节）。在示例中，/dev/diag长度为0x0A的字符串用作参数。

· 缓冲区参数的内容。

图7：用于Fuzzing QDI驱动程序的输入数据文件。

QDI 驱动程序是作为 QuRT ELF 的一部分实现的。它们不在 Qualcomm 的 runelf.pbn 版本的 QuRT 中，我们在模拟器上运行程序。因此，我们必须对runelf.pbnELF文件进行如下修补：

（1）在runelf.pbn中附加用于实际设备的QuRT ELF的程序段。我们使用从Pixel 4设备提取的aDSP二进制数据。

（2）将QDI驱动程序使用的malloc和memcpy内核函数重定向到它们的用户模式实现。内核内存函数限制了用户空间和内核空间之间的一些传输。

图8： QDI驱动程序Fuzzing方案。

AFL fuzzer 传入数据文件的内容，并触发qemu仿真器上的 runelf.pbn 执行。pbn 会加载我们的 QDI _ exec 程序，该程序直接调用 QDI 驱动程序调用函数。

我们通过对QuRT二进制文件进行逆向来手动找到QDI驱动程序调用函数的起始地址。该opener对象位于驱动程序名称旁边的代码中。

该模糊器在Snapdragon 855 aDSP中内置的十二个QDI驱动程序中发现许多crashs，它们中的大多数也适用于cDSP。

2.利用QDI驱动程序中的漏洞

QDI驱动程序中的任何问题都可导致DSP内核崩溃并重新启动移动设备。例如，下面的每一行代码都将引起DSP崩溃，并可以用于设备上的DoS攻击。

出于研究目的，我们成功利用了/dev/i2cQDI驱动程序中的几个任意内核读写漏洞和/dev/glinkQDI驱动程序中的两个代码执行漏洞。出于安全原因，我们无法发布POC代码，但是利用非常简单。这是原语的一个示例：

恶意Android应用程序可以使用QDI驱动程序中发现的漏洞以及用户PD的DSP库中描述的漏洞，在DSP guset OS的上下文中执行自定义代码。

3.从guest OS PD请求Android服务

如果我们尝试从DSP guest OS代码中打开与Android相关的文件，该怎么做呢？答案是QuRT将我们的请求重定向到一个特殊的Android守护程序。如图9所示，在Snapdragon 855设备上，有两个以不同特权运行的aDSP守护程序和一个cDSP守护程序。

图9： DSP Android守护程序。

在Pixel 4设备上，可以在init.sm8150.rc文件中找到这些守护程序的启动命令。

图10：Pixel 4 init.sm8150.rc初始化文件。

这些特权的vendor.adsprpcd和vendor.cdsprpcd守护程序处理DSP guest操作系统的请求。它们以系统用户身份运行，但同时受到SELinux的限制。u:r:adsprpcd:s0和u:r:cdsprpcd:s0上下文只能访问与DSP相关的目录和对象。

0x05 研究总结

aDSP和cDSP子系统是安全研究非常有前途的领域。首先，可以从第三方Android应用程序调用DSP进行访问。其次，DSP处理通过设备传感器传递的个人信息，例如视频和语音数据。第三，正如我们在文章中介绍的那样，DSP组件中存在许多安全问题。

高通将已披露的DSP漏洞分配了CVE-2020-11201，CVE-2020-11202，CVE-2020-11206，CVE-2020-11207，CVE-2020-11208和CVE-2020-11209。对于QDI驱动程序中发现的漏洞，高通公司决定不分配CVE。2020年11月的Qualcomm安全补丁已成功修复所有问题。

出于研究目的，我们利用了一些已发现的漏洞，并获得了在所有基于Snapdragon的移动设备的aDSP和cDSP上执行特权代码的能力。

https://research.checkpoint.com/wp-content/uploads/2021/04/DSP.mp4?_= 

利用截图：