In __host_check_page_state_range of mem_protect

CVE-2026-0030 is an out-of-bounds write in Android's mem_protect.c, specifically the pKVM/virtualization memory-protection path around __host_check_page_state_range, where integer overflow on addr + size was not rejected before range checking. Google fixed it by adding check_add_overflow() guards in the relevant mem_protect functions. The March 2026 Android Security Bulletin lists it under Kernel Components / pKVM, which means this is not a generic app-layer bug; it affects Android builds carrying the vulnerable pKVM hypervisor path and is remediated in the March 2026 security patch train.

The vendor's 8.4/HIGH score is technically defensible in a lab because successful exploitation can yield local privilege escalation with no user interaction. In real enterprise operations, though, this is overstated: the attacker still needs code execution on the device first, then needs the vulnerable pKVM path to be present and reachable on that device class. That combination makes this a post-initial-access kernel/hypervisor escalation issue, not the kind of bug that should displace remotely reachable or actively exploited fleet risks.

Why this verdict

• Downgrade for attacker position: vendor CVSS starts at 8.4, but AV:L here means the attacker needs to already run code on the device. That is a major real-world friction because it assumes an earlier compromise stage.
• Downgrade for population narrowing: this is a pKVM / Kernel Components issue, not a broad remotely reachable Android service. Only a subset of Android devices and usage patterns will meaningfully expose the vulnerable path.
• Downgrade for threat signal: KEV is negative, EPSS is extremely low (0.00007), and no public PoC was found in reviewed sources. That does not make it safe, but it does argue against treating it like an urgent fleet-wide crisis.

Why not higher?

It is not higher because there is no remote entry point in the CVE itself and no sign of active exploitation pressure. The pKVM-specific placement further limits the real exposed population, so this should not outrank remotely exploitable or widely weaponized enterprise vulnerabilities.

Why not lower?

It is not lower because successful exploitation can still convert a local foothold into full device compromise on affected builds. Kernel/hypervisor-adjacent memory corruption remains high-impact on any device where the chain is available, especially if an attacker is already past app-level controls.

1. Enforce managed app allowlisting — Block untrusted APK install paths and restrict sideloading through EMM/MDM policy. Because this is a post-compromise local EoP, reducing the chance of malicious code landing on the device is the best compensating control; for a MEDIUM finding there is no mitigation SLA, so focus on applying this where it is already part of your baseline rather than spinning up an emergency exception process.
2. Prioritize pKVM-capable devices — Use inventory to identify devices that advertise protected VM support or that are on Android builds consuming the March 2026 kernel-component bulletin. This lets you narrow remediation to the slice of the fleet most likely to carry the vulnerable path; with MEDIUM, there is no mitigation SLA — go straight to the remediation window unless your environment treats mobile local EoP as a higher business risk.
3. Harden developer and test devices — Devices used for virtualization, development, research, or broader user-installed software should be patched first because they are more likely to meet the local-code-execution prerequisite. Apply the same application control and USB-debugging restrictions there, even though the formal bucket here remains MEDIUM.
4. Monitor for local exploit precursors — Track app installs from non-approved sources, adb usage, jailbreak/root indicators, and abnormal security posture changes on managed Android endpoints. These signals catch the attacker stage that has to happen before CVE-2026-0030 can be exercised.

Run this on the target Android device through adb shell or your EMM's remote shell. Example: adb shell sh /data/local/tmp/cve-2026-0030-check.sh. No root is required for the patch-level check; the script uses Android system properties and returns PATCHED, VULNERABLE, or UNKNOWN with exit codes 0, 1, and 2.

#!/system/bin/sh
# CVE-2026-0030 exposure check for Android devices
# Logic:
#   - If Android security patch level >= 2026-03-05 => PATCHED
#   - If patch level < 2026-03-05 and pKVM/protected VM support is present => VULNERABLE
#   - Otherwise => UNKNOWN
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

PATCH_CUTOFF="2026-03-05"
SPL="$(getprop ro.build.version.security_patch 2>/dev/null)"
PKVM_PROP="$(getprop ro.boot.hypervisor.protected_vm.supported 2>/dev/null)"
PKVM_FEATURE="$(getprop ro.product.virtual_ab.enabled 2>/dev/null)"

normalize_date() {
  echo "$1" | tr -d '-' | sed 's/[^0-9].*$//'
}

if [ -z "$SPL" ]; then
  echo "UNKNOWN"
  exit 2
fi

SPL_N="$(normalize_date "$SPL")"
CUTOFF_N="$(normalize_date "$PATCH_CUTOFF")"

# First, trust the Android SPL if present.
if [ "$SPL_N" -ge "$CUTOFF_N" ] 2>/dev/null; then
  echo "PATCHED"
  exit 0
fi

# If below cutoff, check whether protected VM support is likely present.
# ro.boot.hypervisor.protected_vm.supported=true is the strongest easy signal available without root.
if [ "$PKVM_PROP" = "true" ]; then
  echo "VULNERABLE"
  exit 1
fi

# If we cannot establish pKVM support, do not claim patched.
# Some devices may be unaffected in practice, but that cannot be proven from these properties alone.
echo "UNKNOWN"
exit 2

Sources

1. NVD CVE-2026-0030
2. Android Security Bulletin — March 2026
3. Android kernel patch aff2255dbe38dc7c57bac8d3ba9feed989289b20
4. Android kernel patch 986614312222d4b3bdcf16840cdb4abdaed8a42d
5. Android AVF architecture / pKVM overview
6. Android virtualization security
7. Linux kernel documentation for Protected KVM
8. CISA Known Exploited Vulnerabilities Catalog