In multiple functions of ffa

CVE-2026-0037 is an Android kernel-side memory corruption bug in arch/arm64/kvm/hyp/nvhe/ffa.c, mapped in the March 2, 2026 Android bulletin to the Protected Kernel-Based Virtual Machine subcomponent. The vendor description says exploitation is local, needs no extra privileges, and needs no user interaction once the attacker already has code execution on the device; the March 2026 bulletin says devices at security patch level 2026-03-05 or later contain the fix.

The raw impact is ugly because kernel or hypervisor-adjacent memory corruption can end in full device compromise. But the vendor's 8.4 baseline overstates enterprise urgency for most fleets: this is not remotely reachable, it usually needs a prior foothold such as a malicious app or physical/ADB access, and the vulnerable code sits in a narrower pKVM/FFA path rather than a universal network-facing service. That keeps it in HIGH, but below panic level.

Why this verdict

• Baseline accepted, then trimmed: vendor score 8.4/HIGH is reasonable for worst-case impact, but I cut it because AV:L means this is not initial access and not remotely wormable.
• Requires prior foothold: the first prerequisite implies the attacker already landed code on the device through some other channel; that is compounding downward pressure in real enterprise environments.
• Reachable population is narrower than 'all Android': AOSP ties this to Protected Kernel-Based Virtual Machine / ffa.c, not a broad user-space service every handset exposes equally.
• Modern controls should block step 1 more often than step 2: app allow-listing, Play Protect, MDM restrictions, and ADB controls remove a lot of practical paths into the vulnerable state.
• No exploitation telemetry amplifier: no KEV listing, no bulletin note of active abuse, and floor-level EPSS keep this out of the top patch queue.

Why not higher?

Because this is not a remote edge bug and not a one-click fleet event. It needs a prior local foothold and then a device/build-specific exploit path, which sharply narrows who can actually use it at scale.

Why not lower?

Because once exploited, this is still a kernel-side privilege escalation on a managed endpoint, and that can expose mail, tokens, work-profile data, and device trust. For enterprises with meaningful Android fleet usage, that is too much downstream blast radius to call merely backlog hygiene.

1. Block untrusted app execution — Enforce managed Play-only installs, application allow-listing, and sideloading bans through MDM/UEM. This directly attacks the main prerequisite for this CVE—local code execution—and for a HIGH verdict should be validated or tightened within 30 days.
2. Disable or restrict ADB and developer options — Use device policy to prevent USB debugging and developer-mode abuse on corporate phones except for tightly controlled admin groups. That removes one of the cleanest local-delivery paths and should be enforced within 30 days.
3. Quarantine non-compliant patch levels — Use UEM compliance rules to flag or restrict devices below Android security patch level 2026-03-05. Conditional access and mail/VPN gating reduce the value of a compromised handset and should be applied within 30 days.
4. Monitor for root and attestation failures — Turn on hardware attestation checks, root detection, and mobile threat defense alerts, then wire them into access decisions for corporate apps. This will not stop exploitation, but it can contain post-exploitation impact and should be operationalized within 30 days.

Run this on an auditor workstation with adb installed and USB/network debugging access to the Android target. Invoke it as ./check-cve-2026-0037.sh <device-serial> or ./check-cve-2026-0037.sh for the default attached device; no root is required, but you need permission to use adb shell on the device.

#!/usr/bin/env bash
# check-cve-2026-0037.sh
# Determine likely exposure to CVE-2026-0037 using Android patch level and basic device facts.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=tool/usage error

set -u

TARGET_SERIAL="${1:-}"
ADB_BIN="${ADB_BIN:-adb}"
REQUIRED_SPL="2026-03-05"

fail() {
  echo "UNKNOWN - $1"
  exit 2
}

need_cmd() {
  command -v "$1" >/dev/null 2>&1 || { echo "UNKNOWN - missing required command: $1"; exit 3; }
}

adb_cmd() {
  if [ -n "$TARGET_SERIAL" ]; then
    "$ADB_BIN" -s "$TARGET_SERIAL" "$@"
  else
    "$ADB_BIN" "$@"
  fi
}

need_cmd "$ADB_BIN"

STATE="$(adb_cmd get-state 2>/dev/null || true)"
[ "$STATE" = "device" ] || fail "adb device not available (state: ${STATE:-none})"

getprop_safe() {
  local key="$1"
  local value
  value="$(adb_cmd shell getprop "$key" 2>/dev/null | tr -d '\r')"
  echo "$value"
}

SPL="$(getprop_safe ro.build.version.security_patch)"
ANDROID_RELEASE="$(getprop_safe ro.build.version.release)"
SDK="$(getprop_safe ro.build.version.sdk)"
MODEL="$(getprop_safe ro.product.model)"
FINGERPRINT="$(getprop_safe ro.build.fingerprint)"
ARCH="$(getprop_safe ro.product.cpu.abi)"

if [ -z "$SPL" ]; then
  fail "could not read ro.build.version.security_patch"
fi

normalize_date() {
  local d="$1"
  if [[ "$d" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
    echo "$d"
  else
    echo ""
  fi
}

SPL_N="$(normalize_date "$SPL")"
REQ_N="$(normalize_date "$REQUIRED_SPL")"

if [ -z "$SPL_N" ] || [ -z "$REQ_N" ]; then
  fail "unparseable patch level (device='$SPL', required='$REQUIRED_SPL')"
fi

echo "Device: ${MODEL:-unknown}"
echo "Android: ${ANDROID_RELEASE:-unknown} (SDK ${SDK:-unknown})"
echo "ABI: ${ARCH:-unknown}"
echo "Patch level: $SPL_N"
echo "Fingerprint: ${FINGERPRINT:-unknown}"

# Lexicographic compare is safe for YYYY-MM-DD format.
if [[ "$SPL_N" < "$REQ_N" ]]; then
  echo "VULNERABLE - security patch level is older than $REQUIRED_SPL"
  exit 1
fi

if [[ "$SPL_N" == "$REQ_N" || "$SPL_N" > "$REQ_N" ]]; then
  echo "PATCHED - security patch level is $SPL_N (>= $REQUIRED_SPL)"
  exit 0
fi

fail "unable to determine status"

Sources

1. Android Security Bulletin — March 2026
2. Android kernel fix commit for CVE-2026-0037
3. NVD record for CVE-2026-0037
4. CVE.org record for CVE-2026-0037
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. FIRST EPSS API documentation
8. Shodan CVEDB page for CVE-2026-0037