In __mfc_handle_released_buf of mfc_core_isr

CVE-2026-0116 is an out-of-bounds write in __mfc_handle_released_buf inside the Exynos/Tensor MFC media driver path. The public fix shows the bug is a missing guard around dec->refcnt before writing into dec->ref_buf[...], which means malformed buffer-release state can push writes past the intended array bounds. Google published it on 2026-03-10; the Pixel bulletin places it in the MFC subcomponent and says security patch level 2026-03-05 or later addresses it on supported Pixel devices.

The vendor-style 9.8/AV:N/UI:N story overstates enterprise reality. This is not an internet-facing daemon you can mass-scan and pop from anywhere; it is a device-side media-driver bug in a specific hardware codec path, on a narrower population than 'all Android'. That said, because it sits below the app sandbox and could plausibly be driven by crafted media on affected phones, it still deserves a HIGH bucket rather than a casual backlog entry.

Why this verdict

• Reachability is overstated: AV:N/UI:N reads like an internet-worm service bug, but the real prerequisite is getting crafted media into a vulnerable MFC hardware path on an affected handset.
• Population is narrower than 'Android': the Pixel bulletin isolates this to MFC, and the public code lives in Exynos/Tensor media-driver trees, which sharply limits exposed fleet percentage versus generic Android CVSS math.
• Threat intel is cold: no KEV, no confirmed exploitation, no public PoC, and very low EPSS all push this below CRITICAL despite the ugly technical impact.

Why not higher?

I am not calling this CRITICAL because every practical prerequisite narrows the field: affected hardware, affected firmware, media-path reachability, and exploit reliability on specific driver builds. If this were a public-internet service with active exploitation or a mature public exploit, the score would jump fast.

Why not lower?

I am not dropping it to MEDIUM because the impact is still a kernel/media-driver memory corruption issue on a widely carried enterprise endpoint class. If weaponized, it can defeat app isolation and compromise high-value mobile identities and data, which is too consequential for a backlog-only label.

1. Enforce the March 2026 Pixel patch baseline — Use MDM/EMM compliance to require security patch level 2026-03-05 or later on supported Pixel devices. For a HIGH verdict, deploy this compensating control within 30 days where direct patch completion is lagging.
2. Quarantine non-compliant mobile devices — Gate access to mail, chat, SSO, and internal apps with conditional access so devices missing the March 2026 patch cannot reach sensitive enterprise data. Apply this within 30 days as the main blast-radius reducer for stragglers.
3. Restrict untrusted app and content sources — Block sideloading, tighten Play Protect / managed app policy, and reduce risky media-ingestion paths on corporate devices. This does not remove the bug, but it lowers the odds that crafted content reaches the vulnerable codec path within the HIGH-severity 30-day mitigation window.
4. Prioritize high-risk cohorts first — Patch executives, admins, developers with privileged mobile access, and any user groups handling sensitive chat/file flows ahead of the rest of the handset fleet. This buys risk reduction quickly while full remediation works through carrier and user lag, and should start within 30 days.

Run this on an auditor workstation with adb and a USB- or network-connected Android device. Invoke it as ./check-cve-2026-0116.sh <serial> or just ./check-cve-2026-0116.sh for the only attached device; it needs no root on the phone, only adb shell access to read system properties.

#!/usr/bin/env bash
# check-cve-2026-0116.sh
# Purpose: Determine likely exposure to CVE-2026-0116 on Google Pixel devices.
# Logic: Pixel devices missing security patch level 2026-03-05 are treated as VULNERABLE.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

TARGET_PATCH="2026-03-05"
SERIAL="${1:-}"

fail_unknown() {
  echo "UNKNOWN: $1"
  exit 2
}

adb_cmd() {
  if [[ -n "$SERIAL" ]]; then
    adb -s "$SERIAL" "$@"
  else
    adb "$@"
  fi
}

command -v adb >/dev/null 2>&1 || fail_unknown "adb not found in PATH"

STATE="$(adb_cmd get-state 2>/dev/null || true)"
[[ "$STATE" == "device" ]] || fail_unknown "no reachable adb device"

getprop_safe() {
  adb_cmd shell getprop "$1" 2>/dev/null | tr -d '\r'
}

MODEL="$(getprop_safe ro.product.model)"
BRAND="$(getprop_safe ro.product.brand)"
PATCH="$(getprop_safe ro.build.version.security_patch)"
RELEASE="$(getprop_safe ro.build.version.release)"
DEVICE="$(getprop_safe ro.product.device)"
HARDWARE="$(getprop_safe ro.hardware)"
SOC_MANUF="$(getprop_safe ro.soc.manufacturer)"
BOARD="$(getprop_safe ro.board.platform)"

[[ -n "$MODEL" ]] || fail_unknown "unable to read device model"
[[ -n "$PATCH" ]] || fail_unknown "unable to read security patch level"

# Normalize likely Google Pixel scope.
IS_PIXEL=0
if [[ "$BRAND" =~ [Gg]oogle ]] || [[ "$MODEL" =~ Pixel ]]; then
  IS_PIXEL=1
fi

if [[ $IS_PIXEL -ne 1 ]]; then
  echo "UNKNOWN: non-Pixel or unrecognized device model ('$BRAND $MODEL'); manual review required"
  exit 2
fi

# Heuristic family match for supported Pixel generations likely carrying the gs/Tensor stack.
AFFECTED_FAMILY=0
if [[ "$MODEL" =~ Pixel\ (6|6a|6\ Pro|7|7a|7\ Pro|8|8a|8\ Pro|9|9a|9\ Pro|9\ Pro\ XL|9\ Pro\ Fold|10|10a|10\ Pro|10\ Pro\ XL|10\ Pro\ Fold|Fold) ]]; then
  AFFECTED_FAMILY=1
fi

# Basic date comparison works because Android patch levels are YYYY-MM-DD.
if [[ "$PATCH" < "$TARGET_PATCH" ]]; then
  if [[ $AFFECTED_FAMILY -eq 1 ]]; then
    echo "VULNERABLE: $BRAND $MODEL | Android $RELEASE | Patch $PATCH | device=$DEVICE | hw=$HARDWARE | soc=$SOC_MANUF | board=$BOARD"
    exit 1
  else
    echo "UNKNOWN: Pixel device with patch level $PATCH older than $TARGET_PATCH, but model family is not in the expected affected set: $MODEL"
    exit 2
  fi
fi

echo "PATCHED: $BRAND $MODEL | Android $RELEASE | Patch $PATCH | device=$DEVICE | hw=$HARDWARE | soc=$SOC_MANUF | board=$BOARD"
exit 0

Sources

1. Android Security Bulletin—March 2026
2. Pixel Update Bulletin—March 2026
3. NVD CVE-2026-0116
4. OpenCVE record for CVE-2026-0116
5. AOSP/Gitiles fix commit for bug 321712082
6. AOSP/Gitiles Exynos tag showing bug 321712082 references
7. CISA Known Exploited Vulnerabilities Catalog
8. Google Pixel update support matrix