In multiple functions of mem_protect

CVE-2026-0038 is a logic error in Android's hypervisor memory-protection code path, with fixes tied to mem_protect.c and related ARM64/pKVM memory-tagging changes. Google shipped it in the March 5, 2026 Android security patch level, and the March 2026 bulletin places it in the Kernel/Hypervisor section; affected Android branches in the bulletin are 14, 15, 16, and 16-qpr2 until they take that patch level, while Samsung says its SMR-MAR-2026 package includes the fix.

The vendor baseline overstates enterprise urgency for most fleets. Yes, successful exploitation is catastrophic on-device, but this is still a *local* bug in a specialized pKVM/AVF path, with no KEV listing, extremely low EPSS, no public exploit found in reviewed sources, and meaningful reachability friction because many real deployments neither expose arbitrary VM creation to apps nor run the relevant protected-VM workflows at scale.

Why this verdict

• Start at 8.4 HIGH: the CVSS impact is real if reached; kernel/hypervisor code exec is full device compromise.
• Drop for attacker position: AV:L means this is *post-initial-access*; the attacker already has code on the handset, which is a major real-world filter for enterprise fleets.
• Drop again for exposure fraction: the vulnerable area is the Android hypervisor/pKVM memory-protection path, not a broadly reachable app framework API; many fleets will never meaningfully expose that path to arbitrary third-party apps.
• Drop again for modern controls: managed Play-only installs, app allowlisting, Play Protect, MTD, and disabled sideloading/ADB should stop or at least sharply reduce Step 1 in normal deployments.
• Drop again for threat intel: no KEV, extremely low EPSS, and no public PoC found means there is no current evidence that attackers are spending time on this at scale.

Why not higher?

It is not higher because this is not remotely reachable and does not create a one-to-many enterprise blast radius on its own. The exploit chain depends on local code execution plus a relatively narrow virtualization/hypervisor path, which is exactly the kind of compound friction that should drag a vendor CVSS score down in operational prioritization.

Why not lower?

It is not lower because the impact is still total on the affected device if someone can hit the path. Also, Android fleets are patch-laggy by nature, and a local app-to-kernel/hypervisor escape remains meaningful wherever sensitive corporate identities, MFA tokens, or managed data live on the handset.

1. Enforce managed app sources only — Block sideloading, unknown sources, and non-approved app stores through EMM/MDM policy. This directly attacks the main prerequisite — local attacker code — and is the highest-value compensating control; for a MEDIUM verdict there is no noisgate mitigation SLA, so push it in the next mobile policy cycle if not already standard.
2. Disable ADB and developer features on production devices — Remove easy local execution paths and reduce physical/debug abuse. Enforce this via device compliance policy and exception-only enrollment; again, no mitigation SLA for MEDIUM, but this should already be baseline mobile hardening.
3. Prioritize pKVM-capable devices for validation — Inventory devices where protected VMs are supported and where virtualization use cases are enabled, then verify patch status there first. This narrows the real exposure set and lets you focus limited testing effort before broad remediation within the 365-day patch window.
4. Quarantine unlocked or integrity-failed devices — Google's AVF security model treats unlocked devices as untrusted for pVM security. Use device attestation/compliance to block corporate access from rooted, unlocked, or integrity-failing handsets while you close patch gaps.

Run this on an auditor workstation that has adb and USB/network debugging access to the target Android device. Invoke it as bash check-cve-2026-0038.sh <device-serial> or omit the serial if only one device is attached; it needs no root on the device, only adb shell access.

#!/usr/bin/env bash
# check-cve-2026-0038.sh
# Determine likely exposure to CVE-2026-0038 on an Android device via adb.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

SERIAL="${1:-}"
ADB=(adb)
if [[ -n "$SERIAL" ]]; then
  ADB+=( -s "$SERIAL" )
fi

need_cmd() {
  command -v "$1" >/dev/null 2>&1
}

if ! need_cmd adb; then
  echo "UNKNOWN: adb not found in PATH"
  exit 2
fi

run_prop() {
  "${ADB[@]}" shell getprop "$1" 2>/dev/null | tr -d '\r'
}

# Basic connectivity check
if ! "${ADB[@]}" get-state >/dev/null 2>&1; then
  echo "UNKNOWN: no reachable adb device"
  exit 2
fi

SPL="$(run_prop ro.build.version.security_patch)"
PKVM="$(run_prop ro.boot.hypervisor.protected_vm.supported)"
ABI="$(run_prop ro.product.cpu.abi)"
MODEL="$(run_prop ro.product.model)"
BUILD="$(run_prop ro.build.fingerprint)"

# Normalize booleans
case "$PKVM" in
  true|1|yes|y|on) PKVM_NORM="true" ;;
  false|0|no|n|off|"") PKVM_NORM="false" ;;
  *) PKVM_NORM="unknown" ;;
esac

TARGET_SPL="2026-03-05"

echo "Model: ${MODEL:-unknown}"
echo "ABI: ${ABI:-unknown}"
echo "Security Patch Level: ${SPL:-unknown}"
echo "Protected VM supported: ${PKVM_NORM}"
echo "Build: ${BUILD:-unknown}"

# SPL should be YYYY-MM-DD and can be compared lexicographically.
if [[ -z "$SPL" || ! "$SPL" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
  echo "UNKNOWN"
  exit 2
fi

if [[ "$SPL" > "$TARGET_SPL" || "$SPL" == "$TARGET_SPL" ]]; then
  echo "PATCHED"
  exit 0
fi

# Pre-March-05 patch level. Now narrow based on likely relevant platform support.
if [[ "$PKVM_NORM" == "true" && "$ABI" == arm64* ]]; then
  echo "VULNERABLE"
  exit 1
fi

# Older SPL but no clear proof the relevant pKVM path is present/reachable.
# Conservative outcome is UNKNOWN rather than PATCHED.
echo "UNKNOWN"
exit 2

Sources

1. Android Security Bulletin — March 2026
2. NVD entry for CVE-2026-0038
3. Android kernel fix commit: prevent donation of non-memory regions
4. Android kernel fix commit: disable Memory Tagging for guests if unsupported
5. Android Virtualization Framework architecture
6. Android Virtualization Framework security model
7. Samsung Mobile Security Bulletin
8. CISA Known Exploited Vulnerabilities Catalog