Qualcomm CVE-2026-21385: when memory-allocation arithmetic goes wrong
Qualcomm’s flaw concerns alignment calculations during memory allocation. The public record describes local access and targeted exploitation, while device-specific patch coverage depends on the manufacturer.
An allocator has to reserve enough memory and put it at a suitable address boundary. CVE-2026-21385 concerns the arithmetic used to meet that alignment requirement. Qualcomm’s description is brief, but it identifies a more specific problem than a generic chipset compromise.
What Qualcomm and Google disclosed
Qualcomm’s CVE record describes memory corruption associated with alignment during memory allocation and classifies the weakness as integer overflow or wraparound, CWE-190. Its CVSS 3.1 score is 7.8, with local access, low privileges and no user interaction in the vector. The affected-product list spans multiple Qualcomm product families. That list is not a reliable substitute for a phone manufacturer’s model-specific update notice.
Qualcomm’s CVE record and affected products
Google’s March 2026 Android bulletin reports indications of limited, targeted exploitation. It states that the March 5 security patch level or later addresses all issues in that bulletin. The bulletin’s separate headline about a critical System remote-code-execution issue should not be applied to this Qualcomm CVE.
Android’s March 2026 security bulletin
The arithmetic behind an aligned allocation
Alignment places an allocation at a boundary suitable for the object or hardware using it. Providing that placement can require extra space, rounding or other bookkeeping beyond the caller’s request. Each intermediate size still has to fit the integer type used to store it.
An integer has a finite range. Arithmetic outside that range may wrap, truncate during conversion, or otherwise lose the intended value, depending on the language and operation. If a size calculation becomes smaller than the amount of memory later accessed, an allocation can appear successful while failing to provide the required capacity. CWE-190 describes this general family of numeric errors.
MITRE’s definition of integer overflow and wraparound
Follow three values through a review: the requested size, the adjusted size and the region actually available for use. A check on the first cannot establish that later arithmetic remains valid. A non-null pointer cannot prove adequate capacity, and correct alignment cannot prove that later accesses stay within it.
Qualcomm does not publish the expression, call sequence, corrupted object or exploit strategy. Those details remain unknown for this CVE; another allocator bug’s mechanics cannot fill them in.
What allocation code needs to preserve
Property | What a correct implementation must preserve |
|---|---|
Representable sizing | Every size adjustment must fit the chosen type before its result is trusted. |
Consistent capacity | The capacity accepted by later operations must not exceed the storage actually provided. |
Valid failure handling | An invalid or impossible request must terminate safely without leaving a usable partial object. |
Check these properties between layers as well as inside a function. A size may be validated in a wide type and narrowed later. The caller and allocator may retain different capacities. Cleanup may assume initialization finished when a validation step actually failed. These are useful questions for the weakness class, not additional findings about Qualcomm’s code.
Regression checks should cover rejected sizes and alignment combinations, the capacity guaranteed by successful allocations, and ownership or capacity metadata left after failure. A single disappearing crash is weaker evidence than checking the allocation contract across those paths.
What the local-access requirement tells us
The published vector specifies local access and low privileges. It does not describe direct invocation by a stranger over Wi-Fi. The flaw can still matter to a chain by increasing the impact of code already on the device, but the advisory does not explain how an attacker first reaches that position.
Android normally separates applications using process identities and kernel-enforced controls, including for native code. A defect in a component reachable from that environment must therefore be assessed according to the authority of the affected component, not just the identity of the application that first encounters it.
Android’s application sandbox model
Match the patch to the device build
Record the exact model, regional or carrier variant, build and security patch level, then check the manufacturer’s coverage for CVE-2026-21385. Current browser and messaging apps do not verify a vendor component’s update. A broad chipset-family match is also insufficient to decide whether a specific build remains affected.
CISA added CVE-2026-21385 to its Known Exploited Vulnerabilities catalog on March 3, 2026. That supports prioritizing verification of affected devices; it does not identify which individual phones were compromised.
CISA’s Known Exploited Vulnerabilities catalog
Close the patch task with a device-reported build mapped to the manufacturer’s corrected release. Assign an owner to any model unable to receive it. If targeting is suspected, preserve and assess that evidence separately; an update cannot establish that earlier access or data theft did not occur.
Source check: September 8, 2026. This is an analysis of public Qualcomm, Android and CISA disclosures. The engineering examples below explain the weakness class; they are not a reconstruction of a private exploit or patch.