CVE-2021-25369

What it actually does

CVE-2021-25369 is a local information disclosure flaw caused by improper access controls on the Samsung Android sec_log interface prior to the SMR MAR-2021 Release 1 security update. A locally installed application or user-space process with low privileges can read kernel log content that should not be exposed outside privileged contexts. The exposed data may include sensitive kernel information such as addresses, memory-layout details, driver state, crash/debug output, or other diagnostic data that can weaken platform hardening and help an attacker develop or stabilize a separate local privilege-escalation exploit. The vulnerability does not directly provide code execution, integrity modification, or denial of service, but it can materially aid post-compromise escalation on affected devices.

Why it matters to the business

An attacker who already has local code execution on an affected Android device, such as through a malicious app or chained exploit, may be able to collect sensitive kernel information that makes deeper device compromise easier. Because this vulnerability is listed in CISA KEV with known exploitation and a remediation due date of 2022-11-29, unpatched affected devices should be treated as exposed to real-world attack activity even though the standalone CVSS score is moderate and EPSS is low and stable. Operational consequences include increased risk of mobile device compromise, bypass of device hardening assumptions, exposure of sensitive diagnostic data, and easier chaining with other Android or vendor-specific privilege-escalation vulnerabilities.

How an attack unfolds

Exploitation requires local access to an affected device, typically through a malicious Android application, an already-compromised app sandbox, physical/local shell access, or another exploit that provides user-space execution. The attacker reads the improperly protected sec_log interface from user space and captures kernel diagnostic output. They then parse the output for kernel addresses, memory layout hints, driver messages, pointers, crash traces, or other data that should normally be restricted. That information can be used to bypass mitigations such as address randomization, improve exploit reliability, or support a chained attack that obtains higher privileges. Public reporting and KEV status indicate this issue has been exploited in the wild; detection should therefore focus on suspicious access to sec_log combined with other mobile exploitation behaviors, privilege-escalation attempts, unknown sideloaded applications, and post-exploitation tooling.

How to fix it

Apply the vendor security update that includes Samsung SMR MAR-2021 Release 1 or later for affected Samsung Android devices. Where devices receive updates through an OEM, carrier, enterprise mobility management platform, or Android Enterprise workflow, verify that the deployed security patch level includes the March 2021 Samsung remediation or a later cumulative update. If direct patching is not immediately possible, reduce exposure by blocking sideloaded applications, enforcing managed app allowlists, disabling unnecessary adb/debug access, restricting physical access, requiring mobile threat defense controls where available, and prioritizing replacement or isolation of devices that can no longer receive vendor security updates. Because this issue is in the CISA Known Exploited Vulnerabilities catalog, remediation should be treated as overdue for any still-affected device population.

How to confirm the fix worked

Confirm that affected devices report a security patch level and vendor firmware build that includes Samsung SMR MAR-2021 Release 1 or later. Validate through device management inventory, Android security patch reporting, OEM firmware version data, or direct device inspection. On representative devices, verify that the sec_log interface is no longer readable by unprivileged applications or shell contexts. A basic validation approach is to attempt to read the sec_log path from a non-root context and confirm access is denied or the sensitive kernel data is unavailable. Also confirm that devices cannot install untrusted apps outside approved channels and that adb/debug access is disabled unless explicitly required and controlled.

Typical attack path

1. Attacker obtains local execution on an affected Android/Samsung device, commonly through a malicious app, sideloaded package, compromised app context, adb shell access, or a separate exploit.
2. The attacker checks whether the vulnerable sec_log interface is present and readable from an unprivileged or low-privileged context.
3. The attacker reads the sec_log content and saves or exfiltrates the kernel diagnostic output.
4. The attacker analyzes the log data for kernel addresses, memory-layout information, driver/debug output, or other sensitive details.
5. The attacker uses the disclosed kernel information to improve a chained exploit, bypass hardening, escalate privileges, or support further device compromise.
6. The attacker may clean up temporary files or rely on normal application behavior to avoid obvious indicators.

How to detect it

Post-exploitation detection is difficult because exploitation can be a simple local file read and may not generate standard Android application logs. Useful sources include mobile EDR or MTD telemetry, Android audit logs where available, adb shell history in test or managed contexts, endpoint forensic images, app behavior telemetry, file-access monitoring, package installation history, and network telemetry for suspicious exfiltration shortly after local file reads. Hunt for untrusted or sideloaded apps, native binaries, shell commands, or app processes attempting to open or copy sec_log from user space. Correlate sec_log access with signs of exploit chaining, including unexpected privilege changes, rooting artifacts, suspicious use of su or magisk-related tooling, crashes in kernel drivers, abnormal SELinux denials, installation of unknown APKs, and outbound connections from recently installed apps. Because known exploitation is reported, also review historical telemetry around the period before remediation for suspicious mobile app installs and low-level system probing. Absence of logs does not prove absence of exploitation; confirm remediation state and inspect high-risk devices if telemetry is limited.

• /proc/sec_log
• sec_log
• cat /proc/sec_log
• cp /proc/sec_log
• dd if=/proc/sec_log
• open /proc/sec_log
• Permission denied /proc/sec_log
• avc: denied
• scontext=u:r:untrusted_app
• tcontext=u:object_r:proc_security:s0
• /system/bin/sh -c cat /proc/sec_log
• /data/local/tmp/sec_log
• /sdcard/sec_log
• /sdcard/Download/sec_log

What your security team should do

• Prioritize identification and update of all affected Samsung Android devices because the vulnerability is KEV-listed and has known exploitation in the wild.
• Verify that mobile device inventory captures OEM, model, firmware build, and Android/Samsung security patch level, not only the generic Android version.
• Push or require installation of firmware containing Samsung SMR MAR-2021 Release 1 or later; quarantine, restrict, or retire devices that cannot be updated.
• Review mobile threat defense, EDR, or device telemetry for suspicious reads of sec_log and for malicious or unknown applications installed around the same time.
• Harden mobile policy by blocking sideloading, restricting adb/debug access, enforcing app allowlists, and requiring managed application stores.
• Treat this vulnerability as a potential link in an exploit chain; investigate alongside signs of local privilege escalation, rooting, persistence, suspicious native binaries, and unusual app permissions.
• Use KEV status and the missed 2022-11-29 remediation deadline to justify accelerated remediation or device replacement for unmanaged or legacy devices.