CVE-2022-22063

CVE-2022-22063 is a security issue in the hypervisor firmware of some older Qualcomm chipsets. An unprotected hardware component (the "boot remapper") can be abused to gain full read/write access to the hypervisor from a modified operating system (privilege escalation). Exploiting the issue is trivial on affected platforms, since knowledge about the specific firmware version (e.g. addresses or variables) is not required.

Note: Although Qualcomm has provided fixes to customers (with plenty time to release updates) many affected devices are already quite old and may not receive the fix from the vendor. The issue can only be exploited from a modified or compromised operating system (using another security issue). Keeping the operating system up-to-date and secure might be sufficient even if the firmware is vulnerable.

Overview

• CVE Identifier: CVE-2022-22063
• Security Rating (Qualcomm): Critical
• Common Vulnerability Scoring System: 8.4 (High), CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Common Weakness Enumeration: CWE-1257: Improper Access Control Applied to Mirrored or Aliased Memory Regions and/or CWE-1262: Improper Access Control for Register Interface, Qualcomm categorizes the issue broadly as CWE-16: Configuration.

The issue was also published in [Qualcomm's December 2022 Security Bulletin].

Requirements

The issue depends on a combination of hardware and software running on the affected target:

1. Software: The device runs a separate Qualcomm-provided "hypervisor" firmware (usually an ELF image in the hyp partition on internal storage).
2. Hardware: There is a non-secure version of the boot remapper (usually configurable using a hardware register called APCS_BOOT_START_ADDR_NSEC), which is not protected by the hypervisor and is therefore accessible by the less privileged operating system kernel (e.g. Linux).

There are several more chipsets which likely have the affected hardware (e.g. MSM8909 and MSM8953), but they do not have a separate hypervisor firmware that could be compromised.

Impact

• Privilege Escalation: Given an already compromised operating system kernel (e.g. Linux), the issue allows trivially elevating privileges to the hypervisor level (EL1 -> EL2 on ARM). All memory managed by the hypervisor can be read or written. This breaks the isolation of different security domains or virtual machines managed by the hypervisor (if any, depending on the configuration).
  (See also: [An introduction to Access Control on Qualcomm Snapdragon Platforms])

• Secure Boot: Most Qualcomm devices available in production make use of secure boot to prevent unauthorized modification of the firmware. The firmware is cryptographically signed and verified by the boot chain. The issue allows modifying or even fully replacing the loaded hypervisor firmware at runtime from a modified operating system (either through officially supported "bootloader unlocking" or another exploit).
  (See also: [Qualcomm Secure Boot and Image Authentication Technical Overview (v1.0)] and (v2.0))

Technical Background

Note: The issue was originally found on the Qualcomm Snapdragon 410 (MSM8916) platform. Some of the following explanations might be specific to MSM8916, e.g.:

• Specific memory addresses
• 64-bit ARM/AArch64 firmware design (some affected platforms support 32-bit ARM/AArch32 only)

However, the general concept applies similarly to all affected platforms.

Hypervisor

The ARMv8-A 64-bit architecture defines 4 privilege levels ("exception levels", EL). There are separate levels that are typically used for applications, operating system kernels and a hypervisor:

The CPU switches between the levels during exceptions, e.g. because of an incoming interrupt. It is also possible to switch between some of the levels using special instructions, such as the Hypervisor Call (hvc).
(See also: [AArch64 Exception model])

The hypervisor can host one or multiple virtual machines with separate operating system kernels. Each virtual machine can be given its own view of memory using stage 2 translation. All memory accesses from a virtual machine pass through two translation stages: the first is managed by the (virtual) operating system, while the second stage is managed by the hypervisor. Memory used by the hypervisor or other virtual machines can be hidden by omitting it from the translation tables.
(See also: [AArch64 virtualization], [AArch64 memory management])

Qualcomm's hypervisor firmware runs in EL2 and uses stage 2 translation to disallow access to the hypervisor memory from the main operating system kernel running in EL1 (usually Linux). Note that in this setup the stage 2 translation is primarily used for memory protection, without address translation. The main operating system gets direct access to most hardware components in the memory-mapped input/output (MMIO) space, e.g. the SD controller or the camera subsystem. Access to memory that belongs to the hypervisor/EL2 (hyp) and secure monitor/EL3 (part of tz) is restricted:

Boot Remapper

The boot remapper is not related to virtualization: It is needed during early boot of a CPU core. On this hardware platform the CPU cores always start execution at address 0x0. The boot remapper is an extra hardware component built around the CPU that remaps the first 64 or 128 KiB (0x00000 - 0x20000) to a configurable memory region.

By default the boot remapper points to the boot ROM (the first code that runs when the device is started). Later the mapping is changed so that the other CPU cores immediately start execution in the EL3 firmware (part of tz) that was loaded into the RAM:

Note how the address accessed by the CPU (within tz) is accessible using two different physical addresses: the real address in RAM (0x8650xxxx) and the remapped address using the boot remapper (0x0000xxxx).

There are actually two separate instances of the boot remapper:

• Secure: Remaps memory accesses made in secure state. This is the instance used for CPU start-up, since the CPU initially begins execution in secure state (EL3). It is configurable using APCS_BOOT_START_ADDR_SEC (= 0x0b010004) but only in secure state.
• Non-secure: Remaps memory accesses made in non-secure state. It is configurable using APCS_BOOT_START_ADDR_NSEC (= 0x0b010008), even in non-secure state.

Both boot remapper instances can be configured using a memory register that contains the base address for the remapped region and two configuration bits: REMAP_EN to enable remapping and BOOT_128KB_EN to remap the first 128 KiB instead of just 64 KiB.

(See also: [Qualcomm Snapdragon 410E Technical Reference Manual rev. D], page 85 and 116)

Concept

Using the knowledge of the previous two sections the basic idea is simple: Use the boot remapper to bypass the memory protection (stage 2 translation) of the hypervisor.