In vpu_mmap of vpu_ioctl

CVE-2026-0106 is a missing bounds check in the Pixel VPU driver path vpu_mmap reached from vpu_ioctl. In plain English: untrusted code already running on the device can ask the driver to map far more physical memory than it should, turning a device-memory mapping into broad kernel memory access. Public CNA data says "Android kernel," but Google's own February 2026 Pixel bulletin scopes it to the VPU Driver; the safest affected-range statement is supported Pixel devices carrying the vulnerable VPU driver before security patch level 2026-02-05.

The vendor-style 9.3 / CRITICAL score overstates real enterprise urgency because the decisive friction is attacker position: this is AV:L and needs code execution on the handset first. That matters. For a defender running a large fleet, this is best treated as a high-value post-compromise privilege escalation: serious because it can turn a sandboxed app foothold into full kernel compromise, but not critical because it is neither remotely reachable nor broadly internet-exposed.

Why this verdict

• Downgrade for attacker position: AV:L means the attacker must already have code execution on the handset; that is a major real-world friction point and makes this post-initial-access.
• Downgrade for exposure population: Google's own bulletin scopes the issue to the Pixel VPU Driver, which is a much smaller exposed population than the raw Google Android label implies.
• Hold at HIGH because impact is real: Project Zero describes a path to mapping kernel memory as userland-readable/writable, which is far beyond a mere denial-of-service and enables full device compromise.

Why not higher?

It is not CRITICAL because this bug does not cross the network boundary by itself. Enterprises do not face internet-wide opportunistic scanning for an Android local driver bug; an attacker must first get code onto the device, and that prerequisite cuts reachable population sharply.

Why not lower?

It should not fall to MEDIUM because the exploit path is unusually potent once the prerequisite is met. This is not a finicky logic flaw with low payoff; the public Project Zero write-up indicates a direct path to kernel memory access and full sandbox escape on affected builds.

1. Block untrusted app installation — Use Android Enterprise / MDM policy to disable sideloading, restrict unknown sources, and enforce app allow-listing where business-feasible. This directly attacks the most important prerequisite: local code execution. For a HIGH verdict, deploy or verify this control within 30 days.
2. Enforce Play Protect and mobile threat defense — Require Google Play Protect to stay enabled and integrate MTD telemetry for detections around malicious apps, privilege escalation behavior, and jailbreak-like anomalies. This is the best practical choke point before the kernel bug is reachable. For a HIGH verdict, verify fleet-wide policy compliance within 30 days.
3. Quarantine stale Pixel patch levels — Use MDM compliance rules to flag or reduce access for Pixel devices reporting security patch levels older than 2026-02-05. This shrinks the live vulnerable population while you work remediation. For a HIGH verdict, put the compliance rule in place within 30 days.
4. Constrain sensitive access from mobile devices — Require conditional access for email, VPN, SSO, and admin portals so a compromised handset cannot automatically pivot into higher-value enterprise systems. Tie access to device compliance, patch level, and attestation status. For a HIGH verdict, complete the access-policy review within 30 days.

Run this on the target Android/Pixel device through adb shell, or push it with your EMM agent if you have shell execution. Example: adb push check_cve_2026_0106.sh /data/local/tmp/ && adb shell sh /data/local/tmp/check_cve_2026_0106.sh. No root is required; it reads standard build properties and reports VULNERABLE, PATCHED, or UNKNOWN.

#!/system/bin/sh
# check_cve_2026_0106.sh
# Determine likely exposure to CVE-2026-0106 on Google Pixel devices.
# Logic:
#   - If not a Google/Pixel-like device: UNKNOWN
#   - If Google/Pixel and security patch < 2026-02-05: VULNERABLE
#   - If Google/Pixel and security patch >= 2026-02-05: PATCHED
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

TARGET_PATCH="2026-02-05"

get_prop() {
  /system/bin/getprop "$1" 2>/dev/null
}

MANUFACTURER="$(get_prop ro.product.manufacturer)"
BRAND="$(get_prop ro.product.brand)"
MODEL="$(get_prop ro.product.model)"
DEVICE="$(get_prop ro.product.device)"
PATCH="$(get_prop ro.build.version.security_patch)"
FINGERPRINT="$(get_prop ro.build.fingerprint)"

norm_date() {
  echo "$1" | tr -cd '0-9-'
}

PATCH_N="$(norm_date "$PATCH")"
TARGET_N="$(norm_date "$TARGET_PATCH")"

IS_GOOGLE=0
case "$(echo "$MANUFACTURER $BRAND $MODEL $DEVICE $FINGERPRINT" | tr '[:upper:]' '[:lower:]')" in
  *google*|*pixel*) IS_GOOGLE=1 ;;
esac

if [ "$IS_GOOGLE" -ne 1 ]; then
  echo "UNKNOWN - non-Google/Pixel device or unable to confirm Pixel-family VPU exposure"
  exit 2
fi

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

# Simple lexical compare works for YYYY-MM-DD format.
if [ "$PATCH_N" \< "$TARGET_N" ]; then
  echo "VULNERABLE - Google/Pixel device with security patch level $PATCH_N (< $TARGET_N)"
  exit 1
fi

if [ "$PATCH_N" \> "$TARGET_N" ] || [ "$PATCH_N" = "$TARGET_N" ]; then
  echo "PATCHED - Google/Pixel device with security patch level $PATCH_N (>= $TARGET_N)"
  exit 0
fi

echo "UNKNOWN - unable to determine status"
exit 2

Sources

1. NVD CVE-2026-0106
2. Google Pixel Update Bulletin — February 2026
3. Android Security Bulletin — February 2026
4. Project Zero issue 463438263
5. OpenCVE record for CVE-2026-0106
6. CISA Known Exploited Vulnerabilities Catalog
7. CVE Details record for CVE-2026-0106