Summary In this advisory we are disclosing a signature verification bypass vulnerability in the Huawei recovery mode. The vulnerability can be used not only to apply unauthentic firmware updates but also to achieve arbitrary code execution in the recovery mode. Combining this advisory with the vulnerability detailed in CVE-2021-40055, an attacker can achieve remote code execution without user interraction from the position of a network MITM. The vulnerability was fixed in February 2022. Vulnerability Details Huawei devices - both those running Android and those running HarmonyOS - implement a proprietary update solution which can be applied in various ways. The methods are all public and differ in how the process is triggered (manually or automatically) and how the update media file to be applied is supplied (downloaded over Wi-Fi or supplied from a memory card).

Summary In this advisory we are disclosing a vulnerability in the Huawei Over-The-Air (OTA) update implementation that allows bypassing SSL protections and execute a Man-In-The-Middle attack. The vulnerability was fixed in March 2022. Vulnerability Details Huawei devices - both those running Android and those running HarmonyOS - use Huawei’s custom implementation for applying OTA updates. OTA updates are packaged into a zip container. The update mechanism has several checks that are meant to ensure the authenticity of OTA images before they are applied: the over-the-air download is supposed to happen over a secure connection to prevent Man-In-The-Middle attacks, the zip file has a cryptographic signature that is verified by the update process, and finally the contents of the zip file include further authentications tags.

Summary During the regular boot sequence, Huawei’s BootROM initializes the UFS hardware and the crypto engine in order to load and verify the next stage bootloader image from flash. However, when run in download mode, which maybe used for factory flashing and repair purposes, a connected host can communicate with the BootROM via USB over a serial communication channel. The basis of the communication is a slightly modified version of XMODEM protocol. The first frame to be sent must be the head chunk, which defines the destination address and the size of the file to be downloaded via the following data chunks.

Summary The NPU device’s kernel driver implements a set of ioctl handlers one of which uses unsanitized user data as an index into a function pointer array. The user provided values can exceed the boundaries of the legitimate array and might cause user controlled values to be called as function pointers. A malicious actor can use this vulnerability to hijack the control flow of the kernel and call arbitrary functions with controlled parameters. The function pointer callsite is protected by clang’s CFI, which reduces the number of function that can be called through this primitive. The mmap handler is exposed through the /dev/davinci0 character device.

Summary The NPU device’s kernel driver implements a custom mmap handler that exposes trusted kernel data to user space. These exposed structures contain sensitive data, including kernel pointers, which can be controlled by a user process. The content of these structures is inherently trusted by the kernel, the pointers are accessed for reading and writing at various places. This provides a very convenient arbitrary kernel read-write primitive that can be abused by an attacker to compromise the integrity of the kernel achieve kernel code execution and gain elevated privileges. The mmap handler is exposed through the /dev/davinci0 character device. Due to the applied selinux policy, access to this device is restricted to the hiaiserver system process.

Summary Due to a bug in the way mappings are closed it is possible to free a kmallocated memory chunk arbitrary times. This vulnerability can be used to craft a use after free scenario against any kernel structure that is allocated from the kmalloc-64 cache. There is rich public literature on how such use after free vulnerabilities can be utilized to compromise the kernel, achieve code execution in kernel context, and elevate privileges of user space processes. Even when modern mitigation is deployed. The mmap handler is exposed through the /dev/davinci0 character device. Due to the applied selinux policy, access to this device is restricted to the hiaiserver system process.

Summary The NPU device’s kernel driver implements a set of ioctl handlers one of which uses unsanitized user data as an offset to retrieve a kernel structure. Fields of the structure are written with user provided values. A malicious actor can use this vulnerability to overwrite kernel memory with controlled data. The mmap handler is exposed through the /dev/davinci0 character device. Due to the applied selinux policy, access to this device is restricted to the hiaiserver system process. Because of these limitations a practical attack would need to target the hiaiserver first. The /dev/davinci0 device exposes a series of ioctl handlers, one of which is devdrv_ioctl_load_stream_buff.

Summary In a previous advisory we disclosed multiple vulnerabilities within the NPU device’s mmap handler and discussed how it exposes sensitive kernel data. This advisory focuses on the implementation errors in the same handler. The mapping function ignores the requested size parameter and fails to back regions of the mapped virtual memory with an actual mapping. Trying to access these holes or requesting an mmap that is smaller than the memory mapped by the kernel driver results in a kernel crash, most likely caused by invalid page accesses. The mmap handler is exposed through the /dev/davinci0 character device. Due to the applied selinux policy, access to this device is restricted to the hiaiserver system process.

Summary During the regular boot sequence, Huawei’s BootROM initializes the UFS hardware and the crypto engine in order to load and verify the next stage bootloader image from flash. However, when run in download mode, which maybe used for factory flashing and repair purposes, a connected host can communicate with the BootROM via USB. In this case, the BootROM acts as a USB1.1 Serial-over-USB gadget, with a single data endpoint. Based on kernel sources, the USB device appears to be a Synopsys DesignWare USB 3.0 controller. Although the implementation of the USB stack in the Linux kernel and the BootROM is quite different (latter is orders of magnitude simpler), the offsets and the register map of the device can be learned from (drivers/usb/dwc3):