In multiple functions of mem_protect

CVE-2026-0032 is an out-of-bounds write in Android's arch/arm64/kvm/hyp/nvhe/mem_protect.c, tied to the pKVM memory-sharing path. Google describes it as a logic error that can lead to local elevation of privilege, and the March 2026 Android bulletin places it in Kernel components / pKVM with fixes shipping under the 2026-03-05 security patch level. In practice, that means affected exposure is not "all Android" in a useful operational sense; it is Android builds carrying the vulnerable pKVM kernel component and missing the March 5, 2026 patch level.

The vendor's HIGH 7.8 score is technically fair in a lab because memory corruption in kernel-adjacent code can end badly. In fleet reality, it overstates urgency: this is local, requires an existing foothold, and Google's own bulletin says the kernel-components section assumes System execution privileges needed. That is a major friction point for real attackers and a major downgrade factor for defenders scheduling patches across thousands of endpoints.

Why this verdict

• Major downgrade: requires local attacker position — AV:L means the attacker is already on the handset. For enterprise prioritization, that is a second-stage exploit, not a front-door compromise.
• Further downgrade: bulletin context says System execution privileges needed — that implies a more privileged starting position than a commodity remote attacker normally has, which compounds the post-initial-access requirement.
• Narrower exposure population — the vulnerable code sits in pKVM mem_protect.c under kernel components, not in the generic app, browser, or media path that touches every device and every user.
• No threat telemetry amplifier — no KEV listing, no authoritative active-exploitation note, and a floor-level EPSS 0.00004 all argue against emergency treatment.
• Impact is still real once chained — successful exploitation can hand over root-level control on a managed Android endpoint, so this is not backlog trash; it just does not deserve remote-RCE urgency.

Why not higher?

There is no unauthenticated remote path, no broad internet exposure, and no current authoritative signal of real-world exploitation. The chain starts after the attacker already has code on the device, and possibly after they already have a privileged local context, which sharply limits reachable population and urgency.

Why not lower?

This is still kernel-adjacent memory corruption with high theoretical impact if successfully weaponized. On enterprise-managed mobile fleets, a rooted handset can undermine compliance, local secrets, and trust in the endpoint, so it deserves scheduled remediation rather than dismissal.

1. Block sideloading — Reduce the chance attackers ever get the local foothold this CVE needs. Enforce this through EMM/MDM policy immediately where possible; for a MEDIUM verdict there is no mitigation SLA, so use it as a risk-reduction control while moving to the 365-day remediation window.
2. Enforce app allow-listing and Play Protect — This bug is most valuable when paired with a malicious app or another on-device foothold. Require Google Play Protect, restrict unknown sources, and tighten enterprise app distribution policy; again, there is no mitigation SLA for MEDIUM, but these controls should be kept in place continuously.
3. Prioritize March 2026 SPL inventory — Use EMM to identify devices with ro.build.version.security_patch earlier than 2026-03-05 and treat them as the candidate set. This is the fastest way to scope the fleet because network scanners cannot see this class of bug; remediate inside the 365-day window.
4. Monitor attestation and root signals — Because this ends in local privilege escalation, post-exploit signals matter more than pre-exploit signatures. Enable device integrity checks, root detection, and compliance actions in your mobile stack and maintain them until all affected devices are patched.

Run this on an auditor workstation with adb installed and USB/network debugging access to the target Android device. Invoke it as ./check_cve_2026_0032.sh <device-serial> for example ./check_cve_2026_0032.sh emulator-5554; it does not require root, but it does require the device to authorize adb.

#!/usr/bin/env bash
# check_cve_2026_0032.sh
# Fleet triage for CVE-2026-0032 using Android security patch level.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/tooling error

set -u

TARGET_PATCH="2026-03-05"
SERIAL="${1:-}"

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

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

if ! "${ADB[@]}" get-state >/dev/null 2>&1; then
  echo "UNKNOWN - adb device not reachable or not authorized"
  exit 2
fi

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

PATCH_LEVEL="$(getprop_safe ro.build.version.security_patch | head -n1 | xargs)"
ABI="$(getprop_safe ro.product.cpu.abi | head -n1 | xargs)"
MODEL="$(getprop_safe ro.product.model | head -n1 | xargs)"
BUILD_FINGERPRINT="$(getprop_safe ro.build.fingerprint | head -n1 | xargs)"

if [ -z "$PATCH_LEVEL" ]; then
  echo "UNKNOWN - could not read ro.build.version.security_patch"
  exit 2
fi

# Basic validation for YYYY-MM-DD
if ! [[ "$PATCH_LEVEL" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
  echo "UNKNOWN - unexpected patch level format: $PATCH_LEVEL"
  exit 2
fi

# Lexicographic comparison is safe for YYYY-MM-DD
if [[ "$PATCH_LEVEL" > "$TARGET_PATCH" || "$PATCH_LEVEL" == "$TARGET_PATCH" ]]; then
  echo "PATCHED - model=${MODEL:-unknown} abi=${ABI:-unknown} patch_level=$PATCH_LEVEL target=$TARGET_PATCH"
  exit 0
fi

# Below target SPL. CVE is in arm64 pKVM code; non-arm64 devices are less certain.
if [[ "$ABI" == arm64* ]]; then
  echo "VULNERABLE - model=${MODEL:-unknown} abi=${ABI:-unknown} patch_level=$PATCH_LEVEL target=$TARGET_PATCH fingerprint=${BUILD_FINGERPRINT:-unknown}"
  exit 1
fi

echo "UNKNOWN - patch level is below $TARGET_PATCH but ABI is ${ABI:-unknown}; manual vendor confirmation recommended"
exit 2

Sources

1. Android Security Bulletin — March 2026
2. NVD CVE-2026-0032
3. OSV ASB-A-439996285
4. Android kernel fix commit 048aebb861d2
5. Android kernel fix commit 33eb6bde43d0
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS project
8. Unverified third-party exploit/tutorial signal