Use After Free in PROCA driver prior to SMR Jan-2026 Release 1 allows local attackers to potentially…

PROCA (Process Authenticator) is the Samsung kernel module that ties running processes back to their signing certificates — it's a load-bearing piece of the Knox trust chain on Galaxy devices. A use-after-free in PROCA means a freed kernel object can be reclaimed and dereferenced, potentially yielding arbitrary code execution in kernel context. Affected builds are Samsung Android devices on firmware *prior to SMR Jan-2026 Release 1* — practically every Galaxy phone, tablet, and ruggedized handset that hadn't pulled the January 2026 Samsung Mobile Release before the disclosure window.

Vendor's HIGH (7.3) is defensible on paper because the impact ceiling is kernel RCE, but the CVSS 4.0 vector itself spells out the friction: AV:L/AC:H/AT:P/PR:L. You need code already executing on the device (a malicious app or a chained RCE), you need to win a race or meet a precise state condition, and you need low-but-nonzero privileges. For a fleet manager triaging *patch urgency*, that puts this firmly in the post-initial-access escalation bucket, not the drive-by panic bucket.

Why this verdict

• Local vector only: AV:L means attacker must already be executing code on the device. That collapses the threat population from "every Galaxy on the internet" to "every Galaxy that runs a malicious app" — orders of magnitude smaller.
• Stacked friction: AC:H (race-window dependent) + AT:P (specific runtime preconditions) + PR:L (must be a real process, not zero-priv). Each of these is a meaningful downward adjustment from the vendor's HIGH baseline.
• Role multiplier — typical role (consumer/enterprise mobile endpoint): chain succeeds in kernel RCE on the device, blast radius is single-device Knox container compromise. Bad, but bounded — does not cross to fleet.
• Role multiplier — high-value role (mobile device acting as MFA/passkey root-of-trust, mobile DLP enforcement point, or BYOD with privileged email/VPN tokens): chain still ends at one device; the attacker can steal that user's session, tokens, and biometric-bound keys, but the lateral pivot is via stolen credentials, not via PROCA itself. This keeps the floor at MEDIUM rather than HIGH because the compromise stays on one endpoint.
• EPSS 0.00127 + no KEV + no public PoC: the empirical exploitation signal is consistent with the friction analysis. Mobile kernel UAFs that get weaponized typically land in commercial spyware (NSO, Intellexa) chains and surface in Citizen Lab / TAG reporting — none here.
• Knox stack mitigates impact: RKP, KDP, KCFI, and Knox attestation each independently raise the bar for reliable exploitation and ensure post-exploit detection via MDM.

Why not higher?

HIGH would require either remote reachability, a credible chain with a remote bug already in play (e.g., a paired browser RCE we have evidence of), or a role multiplier that pivots beyond the single device. None of those conditions are met. PROCA is not a fleet-wide trust anchor in the way a domain controller or IdP is — compromising it on one phone does not compromise other phones.

Why not lower?

LOW would require either no realistic impact or an installed base near zero. Neither applies: kernel-context code execution on a Samsung handset is a serious outcome, the affected base is *every* unpatched Galaxy, and mobile devices in 2026 hold passkeys, MFA tokens, and corporate email sessions. The attack is *hard*, not *impossible* — commercial spyware vendors specialize in exactly this primitive class.

1. Force SMR Jan-2026 R1 (or later) via MDM compliance policy — Set Knox Manage / Intune / Workspace ONE compliance to require the January 2026 patch level. Non-compliant devices lose access to corporate email, VPN, and Conditional Access apps until they update. Per the noisgate mitigation SLA for MEDIUM there is *no mitigation deadline* — but enforcing the compliance gate is a one-week task and worth doing now.
2. Enable Knox Attestation in your MDM check-in flow — Attestation will flag devices where kernel integrity (RKP) reports tampering — your post-exploit detection net. Configure the MDM to revoke device certificates and trigger remote wipe on attestation failure.
3. Block sideloading and unknown sources fleet-wide — Push a Knox policy that disables Install unknown apps and enforces Auto Blocker. This kills the most plausible delivery vehicle for a malicious local process.
4. Restrict Play Store to a managed allowlist for high-risk users — Executives, finance, and admins on managed Galaxy devices should be on a curated allowlist via Managed Google Play. Eliminates the "slipped past Play review" delivery path.
5. Deploy mobile threat defense (Lookout, Zimperium, Pradeo) on managed handsets — MTD provides post-exploit detection signal that MDM alone does not — flagging anomalous syscall patterns, root indicators, and known-malicious packages. Pair the alert pipeline with your existing SIEM.

Run this on an auditor workstation with ADB authorized to the target Samsung device (USB debugging enabled, device unlocked). Invoke as ./check_cve_2026_20971.sh <device-serial> — uses adb -s to query the build patch level. No root required; read-only properties.

#!/usr/bin/env bash
# noisgate verifier: CVE-2026-20971 (Samsung PROCA UAF)
# Exits: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -u

SERIAL="${1:-}"
if [[ -z "$SERIAL" ]]; then
  echo "usage: $0 <adb-device-serial>" >&2
  echo "UNKNOWN"; exit 2
fi

if ! command -v adb >/dev/null 2>&1; then
  echo "adb not found in PATH" >&2
  echo "UNKNOWN"; exit 2
fi

# Confirm device reachable
if ! adb -s "$SERIAL" get-state 2>/dev/null | grep -q device; then
  echo "device $SERIAL not in 'device' state" >&2
  echo "UNKNOWN"; exit 2
fi

# Confirm manufacturer is Samsung
MANUF=$(adb -s "$SERIAL" shell getprop ro.product.manufacturer 2>/dev/null | tr -d '\r' | tr '[:upper:]' '[:lower:]')
if [[ "$MANUF" != "samsung" ]]; then
  echo "device is not Samsung (manufacturer='$MANUF') — CVE-2026-20971 not applicable" >&2
  echo "PATCHED"; exit 0
fi

# Pull security patch level (YYYY-MM-DD)
SPL=$(adb -s "$SERIAL" shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')
if [[ -z "$SPL" ]]; then
  echo "could not read ro.build.version.security_patch" >&2
  echo "UNKNOWN"; exit 2
fi

# Samsung SMR Jan-2026 R1 maps to security patch level 2026-01-01 or later
FIX="2026-01-01"

# Lexical date compare works for YYYY-MM-DD
if [[ "$SPL" < "$FIX" ]]; then
  echo "device $SERIAL SPL=$SPL < $FIX  -> VULNERABLE"
  echo "VULNERABLE"; exit 1
fi

echo "device $SERIAL SPL=$SPL >= $FIX -> PATCHED"
echo "PATCHED"; exit 0

Sources

1. Samsung Mobile Security — January 2026 SMR bulletin
2. NVD — CVE-2026-20971
3. MITRE CVE record — CVE-2026-20971
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS model
6. Samsung Knox — Real-time Kernel Protection (RKP) overview
7. Samsung Knox — Kernel Data Protection (KDP)
8. Android Security — CFI in the kernel