A stack buffer overflow was found in Internationl components for unicode

CVE-2025-5222 is a stack overflow in ICU's genrb tool, specifically SRBRoot::addTag in parse.cpp, triggered while converting crafted resource-bundle input. The bug was reproduced on ICU 76.0.1; NVD later mapped affected upstream trains as releases before 77.1 and before 78.1 depending on branch, and multiple distros backported the fix into older package lines rather than bumping to those upstream versions.

The vendor's 7.0 HIGH is technically defensible if you score the memory-corruption outcome in a vacuum, but it overstates day-two enterprise risk. The attack is *local*, *high complexity*, and *user-interaction dependent*, and it hits a command-line build/localization tool rather than a long-running network-facing service; in most estates that means exposure is concentrated in developer workstations, build runners, and software packaging pipelines.

Why this verdict

• Down from vendor HIGH because attacker position is local: the chain starts at AV:L, which implies the adversary already has code delivery into a workstation, build host, or CI context.
• Further down because it needs execution of a specific tool: the vulnerable component is genrb, so only systems that actually compile ICU resource bundles are in scope; that is a small subset of a 10,000-host estate.
• Further down because real deployments add friction: AC:H + UI:R + compiler hardening mean many environments are more likely to see a crash than clean weaponization, and EDR/runner isolation should constrain the payoff.

Why not higher?

This is not unauthenticated remote, not broadly exposed, and not a common server-side runtime path. Most enterprises can remove 95%+ of the estate from concern immediately because ordinary user endpoints and production servers never invoke genrb.

Why not lower?

It is still a memory-corruption bug with plausible local code execution under the invoking account. On developer laptops, packaging hosts, and CI runners that ingest third-party source or localization files, that can become a meaningful foothold or artifact-tampering opportunity.

1. Constrain genrb to trusted build contexts — Run ICU resource compilation only on managed developer workstations and isolated CI runners, not on general-purpose servers. For a LOW verdict there is no formal mitigation deadline, but do this as backlog hygiene in the same maintenance cycle where you review build-tool exposure.
2. Isolate untrusted builds — If you build third-party or community code, keep those jobs in disposable containers/VMs with no long-lived secrets and no signing keys. That shrinks the local blast radius even if genrb is triggered before the patch lands.
3. Protect artifact-signing and CI credentials — Keep signing keys, package publishing tokens, and repo credentials out of the same execution context as untrusted build jobs. This matters more than the overflow itself because the realistic damage path is CI or developer-account abuse.
4. Inventory actual genrb usage — Prioritize hosts with icu-devtools, package-build roles, or source trees invoking genrb; most other systems can be deprioritized. For LOW, do this during routine vulnerability triage rather than emergency response.

Run this on the target Linux host or build runner that has ICU installed. Invoke it as sudo bash check-cve-2025-5222.sh for package-based checks, or bash check-cve-2025-5222.sh /path/to/icu-source to inspect a source tree directly; root is recommended so RPM changelog queries work reliably.

#!/usr/bin/env bash
# check-cve-2025-5222.sh
# Detect likely exposure to CVE-2025-5222 on Linux hosts.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

SOURCE_ROOT="${1:-}"

patched() {
  echo "PATCHED"
  exit 0
}

vulnerable() {
  echo "VULNERABLE"
  exit 1
}

unknown() {
  echo "UNKNOWN"
  exit 2
}

# 1) Source-tree check: look for upstream fix pattern in parse.cpp
if [ -n "$SOURCE_ROOT" ]; then
  PARSE_CPP=""
  if [ -f "$SOURCE_ROOT/icu4c/source/tools/genrb/parse.cpp" ]; then
    PARSE_CPP="$SOURCE_ROOT/icu4c/source/tools/genrb/parse.cpp"
  elif [ -f "$SOURCE_ROOT/source/tools/genrb/parse.cpp" ]; then
    PARSE_CPP="$SOURCE_ROOT/source/tools/genrb/parse.cpp"
  fi

  if [ -n "$PARSE_CPP" ]; then
    if grep -q 'CharString[[:space:]]\+subtag;' "$PARSE_CPP"; then
      patched
    fi
    if grep -q 'char[[:space:]]\+subtag\[1024\];' "$PARSE_CPP"; then
      vulnerable
    fi
    unknown
  fi
fi

# 2) Debian/Ubuntu package checks
if command -v dpkg-query >/dev/null 2>&1; then
  if dpkg-query -W -f='${Status}' icu-devtools 2>/dev/null | grep -q 'install ok installed'; then
    ver="$(dpkg-query -W -f='${Version}' icu-devtools 2>/dev/null)"
    # Debian 11 backport
    if dpkg --compare-versions "$ver" ge '67.1-7+deb11u1'; then
      patched
    fi
    # Debian 12 / Ubuntu-derived 72.x line backport
    if dpkg --compare-versions "$ver" ge '72.1-3+deb12u1'; then
      patched
    fi
    # Upstream fixed lines commonly seen in custom packages
    if dpkg --compare-versions "$ver" ge '77.1'; then
      patched
    fi
    vulnerable
  fi

  # Fallback if icu-devtools is absent but libicu is present
  for pkg in libicu72 libicu74 libicu76 libicu77 libicu78 libicu67; do
    if dpkg-query -W -f='${Status}' "$pkg" 2>/dev/null | grep -q 'install ok installed'; then
      ver="$(dpkg-query -W -f='${Version}' "$pkg" 2>/dev/null)"
      if dpkg --compare-versions "$ver" ge '72.1-3+deb12u1'; then
        patched
      fi
      if dpkg --compare-versions "$ver" ge '77.1'; then
        patched
      fi
      vulnerable
    fi
  done
fi

# 3) RPM-based checks: changelog marker is safer than upstream version guessing because of backports
if command -v rpm >/dev/null 2>&1; then
  if rpm -q icu >/dev/null 2>&1; then
    if rpm -q --changelog icu 2>/dev/null | grep -q 'ICU-22973'; then
      patched
    fi
    if rpm -q --changelog icu 2>/dev/null | grep -q 'CVE-2025-5222'; then
      patched
    fi
    vulnerable
  fi

  for pkg in libicu libicu-devel icu; do
    if rpm -q "$pkg" >/dev/null 2>&1; then
      if rpm -q --changelog "$pkg" 2>/dev/null | grep -q 'ICU-22973'; then
        patched
      fi
      if rpm -q --changelog "$pkg" 2>/dev/null | grep -q 'CVE-2025-5222'; then
        patched
      fi
      vulnerable
    fi
  done
fi

# 4) Binary-only fallback
if command -v genrb >/dev/null 2>&1; then
  # Binary present but package/source evidence unavailable
  unknown
fi

unknown

Sources

1. NVD CVE record
2. Upstream ICU fix commit 2c667e3
3. Red Hat bug 2368600
4. Red Hat RHSA-2025:12083
5. Debian LTS advisory DLA-4217-1
6. Debian security tracker
7. Ubuntu CVE page
8. Public Debian packaging repo carrying the fix