CVE-2022-22071

What it actually does

CVE-2022-22071 is a local use-after-free vulnerability in Qualcomm Snapdragon chipset/firmware components. The flaw can occur when shell/process memory is freed through an IOCTL munmap operation while process initialization is still in progress. A local attacker with low privileges may be able to trigger stale memory reuse in a privileged execution context, potentially leading to arbitrary code execution, privilege escalation, memory corruption, information disclosure, or device instability. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Affected devices using vulnerable Qualcomm Snapdragon Auto, Compute, Connectivity, Consumer IoT, Industrial IoT, Mobile, and Voice & Music chipsets may be exposed to local privilege escalation and full device compromise after an attacker obtains an initial foothold. Because this vulnerability is listed in CISA KEV with active exploitation in the wild and a remediation due date of 2023-12-26, organizations should treat unpatched affected firmware as a priority risk even though EPSS is low. Operational consequences may include compromised mobile or IoT endpoints, persistence by malware, bypass of normal application sandboxing, theft of sensitive data from devices, tampering with device behavior, and outages or crashes in embedded environments.

How an attack unfolds

An attacker must first gain local code execution on an affected device, typically through a malicious application, a chained browser/application exploit, physical access, or another vulnerability that allows code to run with low privileges. The attacker then interacts with the vulnerable Qualcomm component by issuing crafted IOCTL operations that manipulate memory mapping while process initialization is underway. By forcing the vulnerable code path to free shell/process memory and then reuse the dangling reference, the attacker attempts to corrupt memory in a controlled way. Successful exploitation may allow the attacker to execute code with elevated privileges or in a more trusted execution context, disable security controls, access protected data, or install persistent malware. Public KEV status indicates this issue has been exploited in real-world activity against Qualcomm multiple-chipset deployments, so defenders should consider it a post-compromise privilege-escalation primitive that may be chained with initial-access exploits.

How to fix it

Apply vendor-provided firmware, operating system, or device updates that incorporate Qualcomm’s fix for CVE-2022-22071. Because no universal fixed package version is provided, remediation must be performed through the relevant OEM, carrier, operating-system vendor, embedded-device vendor, or firmware supplier for the specific affected chipset and device model. Prioritize devices and products based on exposure, sensitivity, and whether they contain affected Qualcomm components such as APQ8053, AR8031, AR8035, CSRA6620, CSRA6640, MDM9150, MSM8953, QCA6174A, QCA6390, QCA6391, QCA6426, QCA6436, or QCA6574 firmware. Where immediate patching is not possible, reduce risk by restricting installation of untrusted applications, enforcing mobile/endpoint management controls, disabling unnecessary debug or local shell access, limiting physical access to embedded devices, enabling verified boot and application sandboxing, and monitoring for signs of privilege escalation or device compromise. For managed fleets, confirm that OEM security bulletin levels or firmware builds include Qualcomm’s June 2022 security fixes or later vendor-specific backports.

How to confirm the fix worked

Validate remediation by confirming the device or firmware build includes the OEM or platform vendor patch that addresses Qualcomm CVE-2022-22071. On Android-derived platforms, verify the security patch level and vendor security patch level against the OEM advisory that incorporated Qualcomm’s June 2022 bulletin fixes. For embedded and IoT products, compare firmware image versions, release notes, and chipset BSP/vendor package versions against supplier advisories. Inventory hardware to identify affected Qualcomm chipsets and confirm that each device has received a patched firmware or OS image. Where feasible, perform configuration compliance checks through MDM, EDR, firmware management, or asset management tools. A device should be considered potentially exposed if it uses an affected chipset and is running firmware released before the vendor’s fix or lacks documentation showing the Qualcomm patch was integrated.

Typical attack path

1. Identify a target device using an affected Qualcomm Snapdragon chipset or firmware component.
2. Obtain local code execution with low privileges, such as through a malicious app, exploit chain, or physical/interactive access.
3. Open or interact with the vulnerable Qualcomm device driver or firmware interface that exposes the relevant IOCTL path.
4. Trigger process initialization and issue a crafted munmap-related IOCTL sequence to create a use-after-free condition.
5. Shape heap or memory reuse so the freed object is replaced with attacker-controlled data.
6. Hijack execution flow or corrupt privileged state to escalate privileges or execute code in a trusted context.
7. Use elevated access to access protected data, disable defenses, install persistence, or pivot to additional device resources.

How to detect it

Detection is difficult because exploitation occurs locally in low-level chipset or driver code and may leave few high-level application logs. Focus on evidence of the prerequisite and aftermath: suspicious local code execution, unexpected privilege escalation, unauthorized root access, abnormal kernel or driver crashes, SELinux/permission denials followed by elevated activity, and installation of persistence or surveillance tooling. Relevant log sources include Android logcat, kernel ring buffer logs, tombstones/crash dumps, MDM/EDR telemetry, application installation history, audit logs, firmware integrity events, and device management compliance records. Search for processes opening Qualcomm device nodes and issuing unusual IOCTL or mmap/munmap activity where EDR/audit telemetry is available. Investigate crashes or memory corruption in Qualcomm/vendor driver components around the time unknown applications executed. For mobile fleets, correlate exploitation suspicion with unknown APK installation, sideloading, accessibility abuse, root detection events, SELinux permissive changes, bootloader unlock attempts, or unexpected changes to system partitions. Because this issue is KEV-listed and exploited in the wild, absence of a specific IOC should not be treated as evidence of no compromise; prioritize behavioral forensics and patch verification.

• CVE-2022-22071
• use after free when process shell memory is freed using IOCTL munmap
• Qualcomm Multiple Chipsets Use-After-Free Vulnerability
• ioctl munmap
• IOCTL munmap
• avc: denied
• SELinux is in permissive mode
• init: starting service 'su'
• /system/xbin/su
• /system/bin/su
• /sbin/su
• /system/app/Superuser.apk
• /system/app/Magisk.apk
• /data/adb/magisk
• /cache/recovery/last_log
• /data/tombstones/
• /proc/kmsg
• /dev/qseecom
• /dev/adsprpc-smd
• /dev/ion
• /dev/kgsl-3d0

What your security team should do

• Immediately inventory mobile, IoT, embedded, automotive, and connected-device assets that use affected Qualcomm Snapdragon chipsets or firmware components.
• Prioritize patching because the vulnerability is in CISA KEV and has documented active exploitation in the wild; the CISA due date was 2023-12-26.
• Obtain patched firmware or OS builds from the relevant OEM, carrier, operating-system vendor, or device supplier and deploy them to affected assets.
• For devices that cannot be patched, restrict local code execution paths: block untrusted app installation, disable debug interfaces, limit shell access, and enforce physical access controls.
• Harden managed mobile and embedded devices with verified boot, application allowlisting, MDM compliance policies, and least-privilege controls.
• Review EDR/MDM telemetry and device logs for unexplained privilege escalation, kernel crashes, suspicious IOCTL-heavy local processes, or unauthorized rooting/jailbreak indicators.
• Treat this vulnerability as a likely component in exploit chains and investigate it alongside evidence of malicious apps, browser exploits, or other initial-access activity.
• Require suppliers and device vendors to attest whether their firmware includes the Qualcomm fix and document patched build numbers for procurement and lifecycle tracking.