CVE-2026-21385

What it actually does

This is a local memory-corruption vulnerability in Qualcomm chipset firmware or chipset-adjacent components triggered during alignment handling for memory allocation. A low-privileged local attacker can cause memory to be allocated, addressed, or interpreted incorrectly, potentially corrupting adjacent memory structures and gaining code execution or privilege escalation within the affected device context. Because the CVSS vector indicates local access, low attack complexity, low privileges required, and no user interaction, the most likely technical outcome is escalation from an already-running local process or app to a more privileged execution context, with possible compromise of confidentiality, integrity, and availability of the device.

Why it matters to the business

Affected mobile, embedded, smart audio, smart display, and Snapdragon-based devices may be vulnerable to full device compromise after an attacker first obtains local code execution, such as through a malicious app, chained browser exploit, or prior foothold. Successful exploitation can allow theft of sensitive data, tampering with device behavior, persistence, disabling of security controls, or disruption through crashes and instability. The vulnerability is listed in CISA KEV with a remediation due date of 2026-03-24 and has active exploitation reported in the wild, including association with an Interlock ransomware campaign, which makes timely firmware and vendor patch deployment operationally important even though the KEV entry is not specifically marked as ransomware-used.

How an attack unfolds

An attacker must first obtain the ability to run code locally on an affected Qualcomm-based device, typically through a malicious application, a compromised app process, physical/ADB access, exploitation of another vulnerability, or delivery as part of a multi-stage intrusion chain. The attacker then invokes the vulnerable memory-allocation path using crafted alignment values or allocation patterns that cause memory corruption. If exploitation is reliable, the attacker can manipulate corrupted memory to alter control flow, overwrite security-relevant structures, or execute code in a more privileged context. In real-world campaigns, this class of vulnerability is commonly used after initial access to escape application constraints, elevate privileges, tamper with device telemetry, access protected data, or maintain persistence. Failed exploitation attempts may result in application crashes, subsystem restarts, kernel faults, or device instability.

How to fix it

Apply firmware, operating-system, or vendor security updates that include Qualcomm fixes for CVE-2026-21385 across all affected device families. Because no universal fixed version is provided, remediation should be driven by the device OEM, carrier, Android security bulletin, embedded vendor advisory, or Qualcomm chipset bulletin applicable to each device model and platform. Prioritize assets using Qualcomm SM7675P, SM8475P, SM8550P, SM8635, SM8635P, SM8650Q, SM8750P, Smart Audio 400 Platform, Smart Display 200 Platform, Snapdragon 4 Gen 1, Snapdragon 4 Gen 2, Snapdragon 429, Snapdragon 460, and related firmware builds. Where immediate patching is not possible, reduce risk by restricting installation of untrusted applications, disabling developer/ADB access where not required, enforcing mobile threat defense controls, limiting physical access, using application allowlisting for managed devices, and isolating unpatched embedded or IoT devices from sensitive networks. For end-of-life devices without vendor patches, plan replacement or compensating isolation.

How to confirm the fix worked

Confirm exposure by inventorying devices and firmware against vendor advisories for the affected Qualcomm chipsets and verifying that the installed OEM firmware/security patch level includes the relevant Qualcomm security update. On Android-based devices, validate the OS build, vendor security patch level, baseband/vendor firmware version, and OEM bulletin status rather than relying only on the Android framework patch date. For embedded and smart devices, confirm the vendor firmware release notes explicitly include the Qualcomm memory-corruption fix or a security update issued after the applicable advisory. After remediation, perform controlled regression testing for device stability, confirm no unexpected subsystem restarts or crash loops occur, and verify that application-installation, ADB/debug, and device-management policies remain enforced.

Typical attack path

1. Gain local execution on an affected Qualcomm-based device through a malicious app, chained exploit, physical access, or another compromise vector.
2. Fingerprint the device chipset, firmware, OS build, and patch level to determine whether the vulnerable Qualcomm component is present.
3. Trigger the vulnerable allocation-alignment code path with crafted parameters or repeated allocation patterns.
4. Corrupt memory in a controlled way to influence adjacent objects, allocator metadata, function pointers, or security-relevant structures.
5. Escalate privileges or execute code in a privileged device, firmware, kernel-adjacent, or trusted component context.
6. Disable security controls, access protected data, install persistence, move to follow-on payloads, or intentionally crash/restart affected services to cover activity.

How to detect it

Detection should focus on evidence of attempted local exploitation and post-exploitation rather than a single network signature, because the vulnerability requires local execution and is in firmware or chipset-adjacent code. Collect and review Android logcat, kernel logs, tombstones, crash dumps, MDM/mobile threat defense alerts, EDR telemetry where available, application-installation history, ADB/debug logs, and OEM diagnostic logs. Look for repeated native crashes, segmentation faults, allocator-related aborts, kernel oops/panic events, Qualcomm subsystem restarts, unexplained baseband/DSP/vendor-service resets, privilege escalation attempts, suspicious native binaries dropped by apps, tampering with SELinux/enforcement or security tooling, and unknown processes launching shortly after crash events. Correlate crashes or subsystem restarts with recent installation of untrusted apps, sideloaded APKs, ADB sessions, exploit-chain indicators, or outbound traffic to unfamiliar infrastructure. For fleet investigations, compare vulnerable versus patched firmware cohorts and prioritize devices showing abnormal crash frequency, unexpected root indicators, modified system/vendor partitions, or security patch rollback.

• Fatal signal 11 (SIGSEGV)
• Fatal signal 6 (SIGABRT)
• signal 7 (SIGBUS)
• tombstone_
• /data/tombstones/
• /data/anr/
• subsystem_restart
• Subsystem Restart
• SSR:
• qcom_scm
• qseecom
• kgsl
• ion_alloc
• dma_alloc
• page allocation failure
• kernel BUG
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request
• Oops:
• Kernel panic
• avc: denied
• setenforce 0
• /system/bin/su
• /system/xbin/su
• /vendor/bin/
• adb shell
• adbd

What your security team should do

• Treat this as a high-priority patching item because it is in CISA KEV, has active in-the-wild exploitation, and affects device firmware where compensating controls are limited.
• Build or update an inventory of Qualcomm-based mobile, embedded, smart audio, and smart display assets, including chipset model, OEM firmware version, OS build, and vendor security patch level.
• Prioritize remediation for internet-exposed management surfaces, high-value users, unmanaged/BYOD devices accessing corporate resources, shared operational devices, and embedded devices on sensitive networks.
• Obtain fixed firmware or OS updates from OEMs, carriers, or device vendors and deploy them before or as soon as possible relative to the 2026-03-24 KEV due date.
• For devices without available patches, restrict application sources, disable debugging interfaces, enforce mobile device management posture checks, and isolate or retire unsupported hardware.
• Review device crash, kernel, mobile threat defense, EDR, MDM, and network telemetry for signs of suspicious local privilege escalation, repeated subsystem crashes, or follow-on payload activity.
• Hunt specifically for multi-stage compromise patterns: suspicious app installation followed by native crashes, privilege changes, security-control tampering, unknown binaries, persistence artifacts, or outbound command-and-control traffic.
• Include this vulnerability in ransomware exposure reviews because an Interlock ransomware campaign has been associated with exploitation, even though the KEV ransomware flag is not set.