In MM_DATA_IND of cn_NrSmMsgHdlrFromMM

CVE-2026-0110 is a memory-corruption bug in the Pixel modem path, specifically MM_DATA_IND in cn_NrSmMsgHdlrFromMM.cpp, that Google describes as a possible elevation of privilege. Public Android/Pixel advisories tie it to the Modem subcomponent and state that patch levels 2026-03-05 or later address it on supported Google devices. Inference: despite the CNA CVSS vector saying AV:N/PR:N/UI:N, this is not a normal IP-reachable service; the reachable surface is the cellular/baseband signaling path.

The vendor baseline of CRITICAL 9.8 overstates enterprise patch urgency for most fleets because the hardest part is not memory corruption, it is getting controlled input into the modem from the right attacker position. In practice this looks more like a targeted baseband exploit requiring rogue radio infrastructure, carrier-adjacent capability, or a very specialized telecom lab setup—not an internet worm. It is still serious because exploitation is no-click and below the app layer, but for a 10,000-host enterprise this is a HIGH, not a drop-everything CRITICAL.

Why this verdict

• Baseline starts at 9.8, then drops hard on attacker position: vendor scoring treats this like generic network reachability, but the real prerequisite is modem-path access via telecom infrastructure or equivalent capability.
• Reachable population is narrow: only affected Google/Pixel devices before 2026-03-05 are in scope, and even there the exploit path depends on radio conditions, modem implementation, and carrier context.
• Threat intel is cold: no KEV listing, no authoritative exploitation notice for this CVE, no public PoC found, and EPSS is very low.

Why not higher?

If this were an ordinary internet-facing daemon with the same no-auth/no-click profile, it would stay CRITICAL. But this is a baseband/modem path issue, and each extra prerequisite—radio-path control, device specificity, closed binary behavior—compounds downward pressure on mass exploitation risk.

Why not lower?

It is still a remote, no-click memory-corruption bug in a security-sensitive component, and successful exploitation could compromise a managed mobile endpoint below the app layer. For executives, travelers, journalists, or staff exposed to hostile RF environments, the risk remains materially higher than backlog-grade mobile noise.

1. Enforce Pixel patch compliance — Use MDM or ADB-based compliance checks to identify devices below security patch level 2026-03-05 and drive them to compliance within 30 days. This is the cleanest control because scanner visibility into modem bugs is weak and patch level is the only durable signal.
2. Prioritize high-risk users first — Move executives, administrators, frequent travelers, and field staff onto patched devices first, within 30 days. Their exposure to targeted surveillance and hostile RF environments is the practical amplifier for this bug.
3. Retire unsupported Pixel models — Identify Pixel 5a and earlier devices that no longer receive security updates and remove them from trusted access paths within 30 days if they cannot receive the March 2026 patch train. Unsupported handsets turn a bounded patching problem into permanent residual risk.
4. Reduce risky radio exposure where feasible — For high-risk cohorts, restrict unnecessary roaming/test networks and prefer managed carrier profiles or safer connectivity options until patched, within 30 days. This does not fix the bug, but it reduces opportunities for hostile telecom-path interaction.

Run this on an auditor workstation with adb installed against a USB- or network-connected Pixel device. Invoke it as ./check-cve-2026-0110.sh SERIAL or ./check-cve-2026-0110.sh for the default connected device; no root is required, but the device must allow ADB access.

#!/usr/bin/env bash
# check-cve-2026-0110.sh
# Verify whether a connected Android/Pixel device is patched for CVE-2026-0110
# Logic:
#   - Reads model and security patch level via adb.
#   - Treats SPL >= 2026-03-05 as PATCHED per Google's March 2026 Pixel bulletin.
#   - Outputs VULNERABLE / PATCHED / UNKNOWN and exits non-zero on UNKNOWN/VULNERABLE.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / execution error

set -euo pipefail

TARGET="${1:-}"
ADB=(adb)
if [[ -n "$TARGET" ]]; then
  ADB+=( -s "$TARGET" )
fi

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

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

STATE="$(${ADB[@]} get-state 2>/dev/null || true)"
[[ "$STATE" == "device" ]] || fail_unknown "no accessible adb device"

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

MODEL="$(getprop_safe ro.product.model)"
MANUFACTURER="$(getprop_safe ro.product.manufacturer)"
BRAND="$(getprop_safe ro.product.brand)"
PATCH_LEVEL="$(getprop_safe ro.build.version.security_patch)"
BUILD_ID="$(getprop_safe ro.build.id)"
ANDROID_VER="$(getprop_safe ro.build.version.release)"

if [[ -z "$PATCH_LEVEL" ]]; then
  fail_unknown "security patch level unavailable"
fi

# Normalize date comparison by removing dashes.
PATCH_NUM="${PATCH_LEVEL//-/}"
FIXED_NUM="20260305"

IS_PIXEL="false"
shopt -s nocasematch
if [[ "$MODEL" == Pixel* || "$MANUFACTURER" == "Google" || "$BRAND" == "google" ]]; then
  IS_PIXEL="true"
fi
shopt -u nocasematch

echo "Model: ${MODEL:-unknown}"
echo "Manufacturer: ${MANUFACTURER:-unknown}"
echo "Brand: ${BRAND:-unknown}"
echo "Android: ${ANDROID_VER:-unknown}"
echo "Build ID: ${BUILD_ID:-unknown}"
echo "Security Patch Level: ${PATCH_LEVEL}"

if [[ "$IS_PIXEL" != "true" ]]; then
  echo "UNKNOWN: device does not appear to be a Google Pixel; public fix guidance reviewed was Pixel-specific for CVE-2026-0110"
  exit 2
fi

if [[ "$PATCH_NUM" =~ ^[0-9]{8}$ ]]; then
  if (( PATCH_NUM >= FIXED_NUM )); then
    echo "PATCHED: Pixel security patch level is ${PATCH_LEVEL}, which is at or above 2026-03-05"
    exit 0
  else
    echo "VULNERABLE: Pixel security patch level is ${PATCH_LEVEL}, below 2026-03-05"
    exit 1
  fi
else
  fail_unknown "unrecognized security patch format: $PATCH_LEVEL"
fi

Sources

1. Google Pixel Update Bulletin — March 2026
2. Android Security Bulletin — March 2026
3. Android OSV record PUB-A-440358226
4. Pixel update schedule / checking security patch level
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS data statistics
7. srsRAN Project documentation
8. OpenAirInterface 5G Core Network project