In __pkvm_init_vm of pkvm

CVE-2026-0029 is a memory-corruption bug in Android's protected KVM hypervisor path, specifically __pkvm_init_vm in pkvm.c, caused by a logic error around pVM creation. Google fixed it in the March 2, 2026 Android Security Bulletin, and devices at security patch level 2026-03-05 or later are addressed. In practice, the affected population is narrower than "all Android" because the vulnerable path depends on AVF/pKVM support, protected-VM creation, and relevant common-kernel branches where Google landed the fix commits.

Google's HIGH 8.4 score is technically defensible in a lab because hypervisor memory corruption can be devastating on a single device. In enterprise reality, that label overshoots: the bug is local-only, sits behind Android's virtualization stack, and the VM APIs are restricted rather than broadly exposed to arbitrary third-party apps. That makes this a post-compromise, feature-gated EoP, not a fleet-wide emergency.

Why this verdict

• Start at vendor 8.4: hypervisor-adjacent memory corruption can absolutely be catastrophic on one device if exploited cleanly.
• Down for attacker position: the bug requires local code execution, which means it is not an initial-access problem and already assumes a prior compromise stage.
• Down for exposure population: only devices with AVF/pKVM protected-VM support can reach this path; this is a subset of Android, not the full handset estate.
• Down for permission gating: Google's AVF APIs require restricted MANAGE_VIRTUAL_MACHINE; ordinary third-party apps do not get that by default.
• Keep it above LOW: if the prerequisites line up, the impact is still kernel/hypervisor-level privilege escalation on a managed endpoint.

Why not higher?

It is not higher because every prerequisite compounds downward pressure: local code execution, AVF support, protected-VM support, and restricted VM permissions. That stack of assumptions means most real devices and most malicious apps will never reach the vulnerable function, even before you ask whether the memory corruption is reliably weaponizable.

Why not lower?

It is not lower because the underlying defect sits in a highly privileged kernel/hypervisor path and can plausibly become full device compromise where reachable. Enterprises that deploy preinstalled virtualization-aware apps, custom AVF workloads, or developer-enabled Android fleets still have a meaningful risk concentration.

1. Audit VM-creation permission holders — Enumerate apps holding android.permission.MANAGE_VIRTUAL_MACHINE and remove or constrain any that are not explicitly required. For a MEDIUM verdict there is no noisgate mitigation SLA, but do this during normal hardening work so you reduce the reachable population before patch completion.
2. Prioritize AVF-capable cohorts — Segment managed Android devices by AVF/pKVM capability and Android security patch level, then focus remediation on ARM64 devices with virtualization support and preinstalled enterprise/OEM apps that can create VMs. This narrows the actual vulnerable population instead of treating the whole mobile fleet as equally exposed.
3. Keep Developer Options and adb tightly controlled — Because AVF permissions can be granted for development workflows, lock down adb authorization, USB debugging, and lab-only build practices on production devices. For MEDIUM, there is no mitigation SLA — go straight to the patching program while keeping developer pathways out of production.
4. Block unapproved sideloading — This CVE still needs local code on the device first, so app allowlisting, enterprise app stores, Play Protect, and sideload restrictions remain valuable upstream controls. They do not fix the bug, but they reduce the chance an attacker ever reaches the pKVM path.

Run this on the target Android device via adb shell, or push it to /data/local/tmp and invoke it as adb shell sh /data/local/tmp/check-cve-2026-0029.sh. It needs only normal shell access; no root is required. Example: adb shell sh /data/local/tmp/check-cve-2026-0029.sh.

#!/system/bin/sh
# check-cve-2026-0029.sh
# Determine likely exposure to CVE-2026-0029 on an Android device.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

TARGET_SPL="2026-03-05"

get_spl() {
  getprop ro.build.version.security_patch 2>/dev/null
}

get_arch64() {
  getprop ro.product.cpu.abilist64 2>/dev/null
}

has_avf_feature() {
  cmd package list features 2>/dev/null | grep -q 'android.software.virtualization_framework'
}

has_virt_apex() {
  pm path com.android.virt >/dev/null 2>&1
}

version_ge() {
  # Compares YYYY-MM-DD strings lexicographically.
  # Returns 0 if $1 >= $2
  [ "$1" = "$2" ] && return 0
  [ "$1" \> "$2" ] && return 0
  return 1
}

SPL="$(get_spl)"
ARCH64="$(get_arch64)"
AVF=0
VIRT_APEX=0

if has_avf_feature; then
  AVF=1
fi

if has_virt_apex; then
  VIRT_APEX=1
fi

if [ -z "$SPL" ]; then
  echo "UNKNOWN: unable to read Android security patch level"
  exit 2
fi

# Patched by Android SPL regardless of applicability.
if version_ge "$SPL" "$TARGET_SPL"; then
  echo "PATCHED: security patch level $SPL >= $TARGET_SPL"
  exit 0
fi

# Below patch level: now check whether the vulnerable path is plausibly reachable.
case "$ARCH64" in
  *arm64*) ARM64=1 ;;
  *) ARM64=0 ;;
esac

if [ "$ARM64" -eq 0 ]; then
  echo "PATCHED: device is not ARM64-capable for protected VM path (SPL $SPL is old, but pKVM protected-VM exposure is unlikely)"
  exit 0
fi

if [ "$AVF" -eq 1 ] || [ "$VIRT_APEX" -eq 1 ]; then
  echo "VULNERABLE: SPL $SPL < $TARGET_SPL and device appears to support Android virtualization"
  exit 1
fi

echo "UNKNOWN: SPL $SPL is older than $TARGET_SPL, but AVF/pKVM support could not be confirmed from shell"
exit 2

Sources

1. Android Security Bulletin—March 2026
2. NVD entry for CVE-2026-0029
3. Android common-kernel patch commit ae242b26371808a221578b89c937568781719d2c
4. Android common-kernel patch commit 42eff3b2fd3a906ac8cdb6284d3265bc0856b56b
5. Android common-kernel patch commit 749cf1743eb22eff1851c68a533147e1af97a9bf
6. Android Virtualization Framework API README
7. AVF architecture documentation
8. CISA Known Exploited Vulnerabilities Catalog