Yes. CISA added CVE-2021-25370 to its Known Exploited Vulnerabilities catalogue on 8 November 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Samsung mobile devices using Mali GPU contain an incorrect implementation handling file descriptor in dpu driver. Any organisation running the affected product should treat remediation as urgent.
What active exploitation means for this Samsung mobile CVE
CVE-2021-25370 should be treated as more than a theoretical memory corruption issue because CISA only places a vulnerability in its Known Exploited Vulnerabilities catalogue when it has reliable evidence of active exploitation. For mobile fleets, that changes the response from normal patch planning to urgent exposure verification and containment.
The practical first question is whether any Samsung mobile devices in scope use the affected Mali GPU path in the dpu driver. If you manage a mixed Android estate, focus on device inventory, model mapping, and any fleet segment that still runs the vulnerable software stack. CISA’s KEV entry and the vendor advisory remain the authoritative sources for version and fix details.
Because this is a memory corruption flaw, the security concern is not limited to a crash. Exploitation can potentially create a path to code execution or deeper device compromise, which is why confirmed in-the-wild use materially raises the operational priority. For a broader response playbook on exploited flaws, see Zero-Day and Exploited Vulnerabilities Guide.
How to confirm exposure and reduce blast radius
Start by identifying which mobile device models, OS builds, and managed profiles are actually in use, then compare that inventory against the vendor fix guidance. The important distinction is between devices that merely exist in the organisation and devices that are reachable by users, exposed to untrusted content, or enrolled in high-risk business workflows.
Where the fleet includes personally owned devices, contractor devices, or unmanaged endpoints, treat exposure as wider until proven otherwise. Mobile exposure is often distributed, so remediation effort should be driven by device count, criticality, and user reach rather than by a single server-style patch queue. A mobile hardening baseline such as Mobile Device Security Guide helps frame the inventory and control questions that matter most.
If patching is delayed for any reason, reduce the attack surface around the affected devices. That usually means tightening MDM policy enforcement, limiting risky app installation paths, and restricting access to sensitive internal services from any device that cannot be verified as remediated.
What to do if patching must wait
When an exploit is already active in the wild, delay becomes a risk decision, not just a scheduling issue. If you cannot remediate immediately, isolate the affected population as far as the business will allow, prioritise devices with privileged access, and narrow the services those devices can reach.
For mobile environments, compensating controls are rarely perfect, but they still matter. Restricting trust in device posture, applying stricter access conditions, and using managed compliance checks can buy time while reducing the chance that one compromised handset becomes a gateway to email, chat, VPN, or other internal systems.
Do not rely on generic patch notices alone. In an exploited mobile flaw, the question is whether the device has already been exposed to malicious content or a weaponised chain, and whether that device can still authenticate to systems that matter. If the answer is yes, the device should be treated as a higher-risk endpoint until it is verified clean and updated.
Risk and Threat Considerations
Memory corruption on a widely deployed mobile platform creates a practical attacker advantage because mobile devices are always-on, frequently connected, and often trusted by business systems. Once exploitation is confirmed, the main concern is not only device instability but also attacker footholds that can be used for credential theft, session abuse, or further internal access.
Failure mechanism: The dpu driver’s incorrect handling of a file descriptor can be abused to trigger memory corruption, which may allow an attacker to manipulate device execution state or gain deeper control than the platform intended.
Impact: A successfully exploited device may expose user sessions, internal applications, stored tokens, or other sensitive mobile access paths, making the issue a potential entry point into broader enterprise compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Active exploitation requires rapid identification and remediation of exposed devices. |
| Recommendation — Prioritise remediation of KEV-listed mobile devices and verify closure with repeat scanning. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerability Identification | This question centers on confirming exposure to a known exploited vulnerability. |
| PR.IP-12 — Vulnerability Management | The answer depends on urgent patching and compensating controls for an exploited flaw. | |
| DE.CM-08 — Vulnerability Scans | Verification of exposure and remediation relies on scanning and build-level validation. | |
| Recommendation — Identify affected Samsung devices and rank remediation by exposure and exploitability. Apply a vulnerability management process that accelerates patching of exploited mobile devices. Use authenticated checks to confirm vulnerable builds are removed from the fleet. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | CVE triage and exposure confirmation are direct vulnerability-monitoring activities. |
| Recommendation — Scan managed mobile assets for the vulnerable build and track remediation to completion. | ||
Practitioner Guidance
What to prioritise: Treat CISA KEV inclusion as the trigger for urgent triage, then sort devices by business criticality and access reach. Remediate devices that can reach email, VPN, admin portals, or internal apps first, because those endpoints offer the most useful follow-on access if compromised.
What to verify: Confirm not only that the fix is available, but that the vulnerable device population is actually covered by the rollout. For mobile fleets, partial compliance is common, so verify build-level remediation and do not assume policy enforcement alone has removed the risk.
Practitioner takeaway: For an actively exploited mobile CVE, exposure verification and access reduction matter almost as much as patching, because the real risk is the device’s role as a trusted gateway into the rest of the environment.
Related resources from NHI Mgmt Group
- CVE-2021-25370 (Samsung Mobile Devices Memory Corruption)
- Is CVE-2021-25394 (Samsung Mobile Devices Race Condition) being exploited in the wild?
- Is CVE-2025-21043 (Samsung Mobile Devices Out-of-Bounds Write) being exploited in the wild?
- Is CVE-2023-21492 (Samsung Mobile Devices Insertion of Sensitive Information Into Log File) being exploited in the wild?