In ns_GetUserData of ns_SmscbUtilities

CVE-2026-0113 is an out-of-bounds write in ns_GetUserData inside ns_SmscbUtilities.c, a cellular-modem parsing path tied to SMS Cell Broadcast handling. The CNA text says it can cause remote elevation of privilege with no user interaction; Google's public records only pin the fix to Pixel-family devices at security patch level 2026-03-05 or later, and the Android OSV entry marks the affected range as Pixel-family specific before 2026-03-05.

Google publicly labels the issue High in the March 2026 Pixel bulletin, but for enterprise patch triage that overstates the day-to-day risk. The decisive friction is attacker position: this is not an internet-exposed web service or email client bug, it is a modem-side parser issue that likely requires carrier-path access or a rogue base-station style delivery setup to feed malicious cell-broadcast traffic into the target. That keeps it dangerous but not fleet-fire-drill dangerous.

Why this verdict

• Downward pressure: attacker must control the cellular delivery path rather than just reach an exposed IP service. That implies RF proximity, carrier-side access, or telecom-grade equipment and expertise.
• Downward pressure: reachable population is narrower than the CVE text suggests. Publicly confirmed exposure is tied to supported Pixel-family devices before 2026-03-05, not a broad cross-vendor Android server estate.
• Upward pressure: the bug is still pre-auth remote memory corruption with no UI in a privileged modem parsing path, so it cannot be dismissed as harmless or purely theoretical.

Why not higher?

There is no public exploitation evidence, no KEV inclusion, and no public PoC. More importantly, the path is not internet-scalable: most attackers cannot casually inject malicious cell-broadcast traffic at enterprise targets the way they can spray HTTP, VPN, or email attack surfaces.

Why not lower?

The CNA impact statement is still serious: remote, no user interaction, and memory corruption in a modem-facing parser. If you run a managed Pixel fleet for executives, journalists, field teams, or travelers, the threat model is materially stronger than a routine nuisance bug.

1. Enforce Pixel patch compliance — Use MDM/UEM attestation and compliance policies to identify Google devices below security patch level 2026-03-05 and block them from sensitive access until updated. For a MEDIUM verdict there is no mitigation SLA; use this as an interim control while you work inside the 365-day remediation window.
2. Segment mobile access by trust level — Require stronger conditional access for outdated mobile devices, especially for email, chat, and high-value SaaS sessions. This does not fix the modem bug, but it reduces business impact if a vulnerable handset is compromised before you complete patching.
3. Prefer managed travel profiles for high-risk staff — For executives, journalists, and staff traveling to hostile environments, use the newest patched devices and stricter network/device-trust policies. This is where a specialized RF-path bug matters most, even though there is no noisgate mitigation SLA for a MEDIUM item.
4. Monitor mobile patch drift continuously — Build a standing report for manufacturer=Google and security_patch < 2026-03-05 so this does not disappear into the general Android noise floor. The real control here is inventory discipline, because standard vulnerability scanners will not see this parser directly.

Run this on an auditor workstation with the Android SDK adb tool installed, pointed at a USB-connected or network-connected device with debugging enabled. Invoke it as ./check_cve_2026_0113.sh <device-serial> or omit the serial for a single attached device; no root is required.

#!/usr/bin/env bash
# check_cve_2026_0113.sh
# Verify whether a connected Google Pixel device is patched for CVE-2026-0113
# Logic: Google publicly fixes this issue at security patch level 2026-03-05 or later.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/adb error

set -euo pipefail

TARGET_PATCH="2026-03-05"
SERIAL="${1:-}"
ADB=(adb)

if ! command -v adb >/dev/null 2>&1; then
  echo "UNKNOWN: adb not found in PATH"
  exit 3
fi

if [[ -n "$SERIAL" ]]; then
  ADB+=( -s "$SERIAL" )
fi

# Verify connectivity
if ! "${ADB[@]}" get-state >/dev/null 2>&1; then
  echo "UNKNOWN: no reachable adb device"
  exit 2
fi

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

MANUFACTURER="$(getprop_safe ro.product.manufacturer)"
BRAND="$(getprop_safe ro.product.brand)"
MODEL="$(getprop_safe ro.product.model)"
PATCH="$(getprop_safe ro.build.version.security_patch)"
BUILD="$(getprop_safe ro.build.fingerprint)"

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

# Normalize vendor check for Google Pixel-family devices.
shopt -s nocasematch
IS_GOOGLE=0
if [[ "$MANUFACTURER" == *google* ]] || [[ "$BRAND" == *google* ]] || [[ "$MODEL" == Pixel* ]]; then
  IS_GOOGLE=1
fi
shopt -u nocasematch

if [[ "$IS_GOOGLE" -ne 1 ]]; then
  echo "UNKNOWN: device is not clearly a Google Pixel device"
  echo "manufacturer=$MANUFACTURER brand=$BRAND model=$MODEL patch=$PATCH"
  exit 2
fi

# YYYY-MM-DD sorts lexicographically.
if [[ "$PATCH" < "$TARGET_PATCH" ]]; then
  echo "VULNERABLE: Google device patch level is below $TARGET_PATCH"
  echo "manufacturer=$MANUFACTURER model=$MODEL patch=$PATCH"
  echo "build=$BUILD"
  exit 1
else
  echo "PATCHED: Google device patch level is $PATCH (>= $TARGET_PATCH)"
  echo "manufacturer=$MANUFACTURER model=$MODEL"
  echo "build=$BUILD"
  exit 0
fi

Sources

1. Google Pixel Update Bulletin — March 2026
2. Android Security Bulletin — March 2026
3. Android OSV entry PUB-A-441209133
4. OpenCVE record for CVE-2026-0113
5. CISA Known Exploited Vulnerabilities Catalog
6. srsRAN Project documentation
7. BaseSAFE: Baseband Sanitized Fuzzing through Emulation
8. Google Pixel Help — Check & update your Android version