CVE-2021-25394

What it actually does

This is a local kernel-level use-after-free caused by a race condition in the Samsung MFC charger driver present in affected Android device builds before Samsung SMR MAY-2021 Release 1. If an attacker has already compromised a component running with radio privileges, they can win the race condition and use the stale freed object to perform an arbitrary write in kernel memory. Successful exploitation can lead to kernel memory corruption, privilege escalation, bypass of normal Android process isolation, and compromise of confidentiality, integrity, and availability on the device.

Why it matters to the business

Compromised mobile devices may expose sensitive communications, credentials, enterprise application data, location data, and authentication material, and may also become unstable or unusable. Because this vulnerability is listed in CISA KEV with known exploitation in the wild and the remediation due date was 2023-07-20, unpatched devices should be treated as overdue, higher-priority exposure even though exploitation requires prior compromise of a high-privilege radio component and is technically complex.

How an attack unfolds

An attacker first needs local execution in, or compromise of, a component with radio privileges on an affected Android/Samsung device. From that privileged foothold, the attacker interacts with the vulnerable MFC charger driver and triggers a timing-dependent race that causes the driver to continue using memory after it has been freed. By carefully shaping kernel heap state and winning the race, the attacker turns the use-after-free into an arbitrary kernel memory write. That write can then be used to alter kernel data structures, elevate privileges, disable security controls, persist within the device’s trusted execution path, or access data belonging to other apps and system components. In observed risk terms, this is most likely to appear as part of a chained mobile exploit where an earlier bug obtains code execution or radio privilege and this bug is used to deepen control over the device.

How to fix it

Update affected devices to Samsung SMR MAY-2021 Release 1 or later, or to any later OEM/Android security update that includes the fix for this charger driver issue. Where exact per-device fixed builds vary by model and carrier, validate against the OEM security bulletin and the device’s reported Android security patch level/build number. Retire or isolate devices that cannot receive the May 2021 or later security maintenance release. Use mobile device management controls to block access from noncompliant devices, enforce minimum patch levels, restrict sideloading, and reduce exposure to exploit-chain prerequisites by keeping modem/baseband, vendor, and Android framework patches current.

How to confirm the fix worked

Confirm the device reports an Android/OEM security patch level at or after the vendor release containing Samsung SMR MAY-2021 Release 1. On managed devices, verify inventory through MDM/UEM compliance reports; on test devices, confirm locally through Settings > About phone > Software information or with commands such as `adb shell getprop ro.build.version.security_patch` and OEM build identifiers. Validate that unsupported models are excluded from enterprise access. For exposure assessment, correlate device model, firmware build, carrier build, and security patch level against the OEM bulletin rather than relying only on the generic Android version number.

Typical attack path

1. Identify an affected Android/Samsung device running a build older than SMR MAY-2021 Release 1.
2. Obtain an initial privileged foothold, specifically access to a component running with radio privileges, often through a separate vulnerability or exploit chain.
3. Trigger the vulnerable MFC charger driver code path repeatedly to create the race condition.
4. Manipulate kernel heap timing and object reuse so the driver accesses freed memory.
5. Convert the use-after-free into an arbitrary kernel memory write.
6. Use the kernel write primitive to elevate privileges, weaken security controls, access protected data, or maintain control of the device.
7. Clean up obvious crash artifacts or continue with post-exploitation actions such as data collection or surveillance.

How to detect it

There are no broadly reliable public indicators that uniquely prove exploitation of this vulnerability, and successful kernel-level mobile exploitation may leave little user-visible evidence. Detection should focus on retrospective mobile forensics and anomaly review for affected devices that were unpatched during the exposure window. Review MDM/UEM telemetry for devices with pre-May-2021 security patch levels, unexpected rooting/jailbreak indicators, disabled security services, unexplained compliance state changes, unusual app installations, or repeated crashes/reboots. Collect Android bugreports, kernel logs, tombstones, logcat output, and vendor crash reports where available, looking for kernel panics, memory corruption, use-after-free symptoms, or crashes involving charger, battery, power-supply, MFC, radio, RIL, modem, or vendor kernel components. Because exploitation requires radio privilege, also investigate anomalies in baseband/modem services, radio interface layer processes, unexpected changes to telephony behavior, and suspicious privileged processes. If high-value devices were exposed and show unexplained instability or compromise indicators, perform full mobile forensic acquisition or replace/reimage the device rather than relying only on log review.

What your security team should do

• Immediately identify Android/Samsung devices running pre-May-2021 security maintenance releases and prioritize remediation because the issue is in CISA KEV and exploitation has been reported in the wild.
• Enforce MDM/UEM compliance rules requiring SMR MAY-2021 Release 1 or later, with quarantine or access restrictions for devices that cannot be updated.
• Prioritize investigation of high-risk users and devices that had delayed patching, abnormal radio/modem behavior, unexplained reboots, or signs of mobile compromise.
• Harden mobile fleet controls by disabling sideloading where possible, enforcing app allowlisting, and ensuring modem/baseband and vendor patches are included in routine update compliance.
• For devices that cannot be forensically trusted or cannot receive updates, replace them rather than relying on compensating controls alone.
• Monitor threat intelligence for mobile exploit-chain reporting involving Samsung Android kernel or radio-privileged components, since this vulnerability is most likely used after an earlier compromise step.