In vpu_open_inst of vpu_ioctl

CVE-2026-0112 is a local elevation-of-privilege bug in the Pixel VPU driver path, specifically vpu_open_inst in vpu_ioctl.c, where a race can produce a use-after-free condition. The practical target set is Google Pixel-family devices carrying the affected VPU driver bits before the 2026-03-05 security patch level; Google tracks it in the March 2026 Pixel bulletin as subcomponent VPU with bug ID A-463676597.

The vendor's HIGH 7.4 is technically defensible in a lab because kernel-level impact is severe once triggered, but it overstates enterprise urgency. This is not remotely reachable, not broadly internet-exposed, not KEV-listed, and not showing real exploitation heat; an attacker still needs code execution on the phone first, then must win a high-complexity race in a device-specific driver. For defenders managing large fleets, that is classic downward friction, so this lands in MEDIUM.

Why this verdict

• Start at 7.4, then subtract for attacker position: AV:L means the attacker must already run code on the phone. In enterprise terms, that implies prior compromise, malicious app install, physical access, or an existing exploit chain.
• Subtract again for reachability: this is a Pixel VPU issue, not a generic Android remote service. That sharply narrows the exposed population compared with the headline 'Android' label.
• Subtract for exploitation friction: Google/CISA mark it AC:H, and race-condition kernel bugs are reliability problems in the real world. Modern controls like Play Protect, app-install restrictions, EMM policy, and SELinux raise the bar before the bug is even exercised.
• Do not subtract to LOW because impact is still real: if exploitation succeeds, the attacker can punch out of app sandboxing and gain elevated privilege on a managed device holding enterprise mail, tokens, or VPN creds.

Why not higher?

There is no remote entry point here. No KEV listing, no public exploitation evidence in the reviewed sources, no public PoC found, and no internet-exposed service to mass-scan or mass-weaponize. For a 10,000-host defender, this is not the kind of bug that suddenly turns into fleet-wide compromise from the edge.

Why not lower?

This still lands in the kernel/driver privilege-escalation class, and a successful local privesc on corporate mobile devices can break app sandboxing and increase post-compromise blast radius. If you run a meaningful Pixel estate, especially for executives or privileged admins, ignoring it would understate the consequence of a successful chain.

1. Block sideloading — Use EMM/MDM policy to restrict unknown sources and developer-mode abuse, because this CVE needs local code execution first. For a MEDIUM verdict there is no mitigation SLA, so treat this as mobile hardening hygiene and enforce it during the normal remediation window rather than as an emergency change.
2. Enforce Play Protect and app allowlisting — Keep Google Play Protect enabled and prefer managed Play/app allowlists so untrusted apps cannot become the launchpad for local exploitation. There is no mitigation SLA at MEDIUM, but this control is worth validating now because it directly attacks the biggest prerequisite in the chain.
3. Inventory Pixel patch levels — Use your UEM/EMM to identify Google Pixel devices below 2026-03-05 and separate them from non-Pixel Android devices that are not in scope for this advisory. There is no mitigation SLA at MEDIUM; this inventory should feed the remediation campaign inside the 365-day patch window.
4. Limit adb and developer options — Disable or alert on USB debugging and unauthorized adb usage where policy allows, because exploit development and validation on Android commonly lean on that path. This is not an emergency control for MEDIUM, but it reduces local exploitability and should be folded into baseline mobile controls.

Run this from an auditor workstation with adb installed and a USB- or enterprise-debug-connected device selected. Invoke it as ./check_cve_2026_0112.sh or ANDROID_SERIAL=<serial> ./check_cve_2026_0112.sh; no root is required, but the device must be reachable via adb.

#!/usr/bin/env bash
# CVE-2026-0112 verifier for Google Pixel devices
# Checks whether the connected device is likely patched based on Android security patch level.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / could not assess

set -euo pipefail

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

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

need_cmd adb

ADB_ARGS=()
if [[ -n "${ANDROID_SERIAL:-}" ]]; then
  ADB_ARGS=(-s "$ANDROID_SERIAL")
fi

if ! adb ${ADB_ARGS[@]} get-state >/dev/null 2>&1; then
  echo "UNKNOWN - no adb device available"
  exit 2
fi

brand="$(getprop_safe ro.product.brand)"
manufacturer="$(getprop_safe ro.product.manufacturer)"
model="$(getprop_safe ro.product.model)"
patch="$(getprop_safe ro.build.version.security_patch)"

if [[ -z "$patch" ]]; then
  echo "UNKNOWN - security patch level unavailable"
  exit 2
fi

# This CVE is documented in the Pixel bulletin; non-Google devices are out of scope.
if [[ "${brand,,}" != "google" && "${manufacturer,,}" != "google" ]]; then
  echo "UNKNOWN - device is not a Google/Pixel-family device (brand=$brand manufacturer=$manufacturer model=$model patch=$patch)"
  exit 2
fi

fixed_patch="2026-03-05"

# YYYY-MM-DD strings compare lexicographically.
if [[ "$patch" > "$fixed_patch" || "$patch" == "$fixed_patch" ]]; then
  echo "PATCHED - Google device patch level $patch is at or above $fixed_patch (model=$model)"
  exit 0
fi

echo "VULNERABLE - Google device patch level $patch is below $fixed_patch (model=$model)"
exit 1

Sources

1. Google Pixel Update Bulletin — March 2026
2. Android Security Bulletin — March 2026
3. OSV record PUB-A-463676597 / CVE-2026-0112
4. OpenCVE record for CVE-2026-0112
5. Android security acknowledgements
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview