In dhd_tcpdata_info_get of dhd_ip

CVE-2026-0109 is a denial-of-service flaw in dhd_tcpdata_info_get inside Android/Google Wi-Fi driver code (dhd_ip.c). The public description says no auth and no user interaction are needed, but the strongest authoritative scoping we found is Google's Android OSV entry for A-438245439, which narrows the affected range to the Pixel Watch family fixed at security patch level 2026-03-05; Google's Pixel March 2026 bulletin also tags it as Wifi and Moderate.

The 7.5 HIGH vector overstates operational risk for enterprise patch triage. CVSS treats this as generic network reachability, but in the real world the attacker likely needs RF proximity or a path through the local Wi-Fi environment, the impact is DoS only, there is no KEV listing, no public exploitation evidence, and the affected population appears far narrower than 'all Android'.

Why this verdict

• Attacker position downgrades this hard: a Wi-Fi driver flaw implies local wireless adjacency or equivalent path, not broad internet exposure.
• Exposure population is narrow: the best version intelligence found points to Pixel Watch family rather than your general Windows/Linux/macOS fleet.
• Impact is DoS only: no code execution, no privilege gain, no data compromise, and usually one device at a time.
• Exploit pressure is weak: no KEV, no public exploitation evidence, and a very low EPSS signal.
• Public exploitability is hampered: no public PoC found and the Android bug reference is non-public, which raises implementation friction.

Why not higher?

A higher severity would require either internet-scalable reachability, demonstrated exploitation, or broader blast radius. We have none of those here. The attack likely starts from local wireless position, lands on a narrow device family, and only produces availability loss.

Why not lower?

It is still a genuine remotely triggerable driver-level DoS with no user interaction once the attacker has the right position. If you actually manage affected Google wearables or similar devices in executive/VIP populations, nuisance disruption is real enough that this should not be ignored entirely.

1. Inventory affected Google wearables — Use MDM or asset data to identify any Pixel Watch family devices below security patch level 2026-03-05. Because this is a LOW verdict, there is no mitigation SLA; do this as backlog hygiene during the next normal mobile security review.
2. Restrict risky Wi-Fi exposure for sensitive users — For executives, admins, and field staff carrying affected devices, prefer trusted SSIDs and disable unnecessary Wi-Fi use in hostile environments until patched. This trims the only realistic attack surface—local wireless reachability—and for a LOW issue it belongs in the normal hardening cycle, not emergency change windows.
3. Monitor for repeated Wi-Fi instability — Pull MDM, system, or support telemetry for repeated disconnects, Wi-Fi resets, or crash loops on affected devices. That will not prove exploitation, but it gives you a way to spot nuisance abuse while patching through the regular device-update process.
4. Enforce current Android/Pixel patch baselines — Make 2026-03-05 or later the minimum acceptable patch level for the scoped Google devices in MDM compliance policy. For a LOW issue this is standard configuration hygiene rather than an urgent mitigation program.

Run this from an auditor/admin workstation that has adb installed, with the target Google watch/Android device connected and authorized for debugging. Invoke it as ./check_cve_2026_0109.sh <serial> or ./check_cve_2026_0109.sh for a single attached device; no root is required, but USB debugging or equivalent adb access is.

#!/usr/bin/env bash
# check_cve_2026_0109.sh
# Determine likely exposure to CVE-2026-0109 using Android/Google patch level data.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0 patched, 1 vulnerable, 2 unknown, 3 usage/runtime error

set -u

TARGET_SERIAL="${1:-}"
FIXED_SPL="2026-03-05"

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

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

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

if ! have_cmd adb; then
  echo "UNKNOWN: adb not found in PATH"
  exit 2
fi

STATE=$(adb_cmd get-state 2>/dev/null || true)
if [[ "$STATE" != "device" ]]; then
  echo "UNKNOWN: no authorized adb device connected"
  exit 2
fi

MODEL=$(getprop_safe ro.product.model)
DEVICE=$(getprop_safe ro.product.device)
PRODUCT=$(getprop_safe ro.build.product)
BRAND=$(getprop_safe ro.product.brand)
MANUFACTURER=$(getprop_safe ro.product.manufacturer)
FINGERPRINT=$(getprop_safe ro.build.fingerprint)
SPL=$(getprop_safe ro.build.version.security_patch)
BUILD_ID=$(getprop_safe ro.build.id)

if [[ -z "$SPL" ]]; then
  echo "UNKNOWN: could not read security patch level"
  exit 2
fi

# Heuristic: Google/Pixel watch-family scoping is the strongest public version signal.
IS_GOOGLE=0
if echo "$BRAND $MANUFACTURER $MODEL $DEVICE $PRODUCT $FINGERPRINT" | grep -Eiq '(google|pixel)'; then
  IS_GOOGLE=1
fi

IS_WATCH_FAMILY=0
if echo "$MODEL $DEVICE $PRODUCT $FINGERPRINT" | grep -Eiq '(watch|eos|r11|pixelwatch|pixel_watch)'; then
  IS_WATCH_FAMILY=1
fi

if [[ "$IS_GOOGLE" -ne 1 ]]; then
  echo "UNKNOWN: device does not appear to be a Google/Pixel target"
  exit 2
fi

# Lexical compare works for YYYY-MM-DD dates.
if [[ "$SPL" < "$FIXED_SPL" ]]; then
  if [[ "$IS_WATCH_FAMILY" -eq 1 ]]; then
    echo "VULNERABLE: Google watch-family device below fixed SPL ($SPL < $FIXED_SPL); model=$MODEL build=$BUILD_ID"
    exit 1
  else
    echo "UNKNOWN: Google device below fixed SPL ($SPL < $FIXED_SPL) but public scoping is inconsistent; model=$MODEL build=$BUILD_ID"
    exit 2
  fi
else
  if [[ "$IS_WATCH_FAMILY" -eq 1 ]]; then
    echo "PATCHED: watch-family device at or above fixed SPL ($SPL >= $FIXED_SPL); model=$MODEL build=$BUILD_ID"
    exit 0
  else
    echo "PATCHED: Google device at or above March 2026 fixed SPL ($SPL >= $FIXED_SPL); model=$MODEL build=$BUILD_ID"
    exit 0
  fi
fi

Sources

1. Google Pixel Update Bulletin — March 2026
2. Android Security Bulletin — March 2026
3. NVD CVE-2026-0109
4. Android OSV entry PUB-A-438245439
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. FIRST API documentation for EPSS
8. OpenCVE summary for CVE-2026-0109