In mfc_dec_dqbuf of mfc_dec_v4l2

CVE-2026-0117 is an out-of-bounds write in mfc_dec_dqbuf inside the MFC/V4L2 media path, yielding local elevation of privilege. The authoritative scope is narrower than the generic Android wording suggests: OSV tags it as Pixel-family specific and marks it fixed at the 2026-03-05 security patch level, while the Pixel March 2026 bulletin lists it under the MFC subcomponent as EoP High.

The vendor's 8.4/HIGH score is technically defensible in a lab because successful exploitation can plausibly end in kernel-level compromise with no user interaction. In enterprise reality, though, the biggest fact is the one CVSS hides in plain sight: AV:L means the attacker already has code execution on the phone, so this is mostly a stage-two privilege escalator with a narrower affected population and no current exploitation signal.

Why this verdict

• Started from vendor 8.4/HIGH because successful exploitation can plausibly deliver full device compromise
• Minus for attacker position: AV:L means the adversary already runs code on the device, which implies a prior compromise stage and sharply narrows reachable targets
• Minus for exposure population: OSV marks the issue Pixel-family specific, so this is not a broad all-Android emergency
• Minus for threat evidence: no KEV listing, no public PoC located in reviewed sources, and only 0.01% EPSS signal

Why not higher?

There is no sign this is crossing the line from technical severity into operational urgency. Without remote reachability, KEV status, public weaponization, or exploitation evidence, treating it like a top-tier emergency for a 10,000-device fleet would waste scarce patching attention.

Why not lower?

Once malicious code is already on an affected device, this is still a serious privilege boundary failure with high-impact outcomes. On managed mobile fleets, a successful local privesc can break work-profile isolation, undermine MTD/EDR, and expose enterprise credentials or data.

1. Enforce trusted-app-only policy — Reduce the only practical entry condition: local code execution. Keep Play-only or allowlisted enterprise app install policies in place and review exceptions now; for a MEDIUM verdict there is no mitigation SLA, so do this in the normal hardening cycle while driving remediation inside the 365-day patch window.
2. Disable sideloading and USB debugging — This removes two common ways attackers and red teams land local code on managed phones. Push the policy through MDM for all non-developer cohorts; again, there is no mitigation SLA here, so treat it as standard fleet hygiene rather than an emergency block.
3. Prioritize risky cohorts — Developer devices, executive devices, test phones, and users with broader app install freedom have the highest chance of satisfying the local-execution prerequisite. Re-scope those groups first in your mobile vulnerability dashboard and fold them into the next update wave.
4. Monitor unusual media-device access — If your mobile telemetry stack exposes suspicious codec or device-node access, alert on apps touching video/codec paths without a legitimate business reason. This is a weak but useful tripwire for exploitation attempts and post-exploitation testing.

Run this on the target Android/Pixel device via adb shell sh /data/local/tmp/check-cve-2026-0117.sh or through your MDM agent's shell task runner. It needs only normal shell access; root is not required. The script checks whether the device looks like a Google/Pixel-class target and whether its ro.build.version.security_patch is earlier than 2026-03-05.

#!/system/bin/sh
# check-cve-2026-0117.sh
# Purpose: best-effort verification for CVE-2026-0117 exposure on Android/Pixel devices
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

TARGET_SPL="2026-03-05"

getp() {
  getprop "$1" 2>/dev/null
}

normalize_date() {
  echo "$1" | tr -d '-'
}

SPL="$(getp ro.build.version.security_patch)"
BRAND="$(getp ro.product.brand)"
MANUFACTURER="$(getp ro.product.manufacturer)"
MODEL="$(getp ro.product.model)"
DEVICE="$(getp ro.product.device)"

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

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

# OSV marks this issue Pixel-family specific. If this does not look like a Google device,
# we cannot confidently label it vulnerable from patch level alone.
if [ "$IS_GOOGLE" -ne 1 ]; then
  echo "UNKNOWN"
  echo "reason=non_google_or_non_pixel_scope"
  echo "brand=$BRAND"
  echo "manufacturer=$MANUFACTURER"
  echo "model=$MODEL"
  echo "device=$DEVICE"
  echo "security_patch=$SPL"
  exit 2
fi

SPL_NUM="$(normalize_date "$SPL")"
TARGET_NUM="$(normalize_date "$TARGET_SPL")"

case "$SPL_NUM" in
  ''|*[!0-9]*)
    echo "UNKNOWN"
    echo "reason=unparseable_security_patch"
    echo "security_patch=$SPL"
    exit 2
    ;;
esac

HAS_VIDEO=0
ls /dev/video* >/dev/null 2>&1 && HAS_VIDEO=1

if [ "$SPL_NUM" -ge "$TARGET_NUM" ]; then
  echo "PATCHED"
  echo "brand=$BRAND"
  echo "manufacturer=$MANUFACTURER"
  echo "model=$MODEL"
  echo "device=$DEVICE"
  echo "security_patch=$SPL"
  exit 0
fi

# Pre-fix Google device. Presence of /dev/video* increases confidence that media device nodes exist,
# but absence does not prove safety because access may be hidden or restricted.
if [ "$HAS_VIDEO" -eq 1 ]; then
  echo "VULNERABLE"
  echo "brand=$BRAND"
  echo "manufacturer=$MANUFACTURER"
  echo "model=$MODEL"
  echo "device=$DEVICE"
  echo "security_patch=$SPL"
  echo "evidence=pre_2026_03_05_patch_and_video_nodes_present"
  exit 1
fi

echo "VULNERABLE"
echo "brand=$BRAND"
echo "manufacturer=$MANUFACTURER"
echo "model=$MODEL"
echo "device=$DEVICE"
echo "security_patch=$SPL"
echo "evidence=pre_2026_03_05_patch_level"
exit 1

Sources

1. NVD CVE record
2. Android Security Bulletin—March 2026
3. Pixel Update Bulletin—March 2026
4. OSV record PUB-A-337803567
5. OpenCVE record
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview and API documentation
8. Pixel Help: check Android security patch level