In the Linux kernel

CVE-2025-71204 is a refcount leak in the Linux kernel's ksmbd SMB server path parse_durable_handle_context(). The bad path is hit when a durable-handle replay operation returns -ENOEXEC and the associated ksmbd_file reference is not released, so repeated triggering can pin kernel objects and degrade availability over time. Upstream affected ranges published by Linux/NVD are 6.6.32 through 6.6.123, 6.9 through 6.12.69, 6.13 through 6.18.9, plus 6.19-rc1 through 6.19-rc3; fixes land in 6.6.124, 6.12.70, 6.18.10, and 6.19.

The vendor/NVD MEDIUM 5.5 baseline is defensible in a lab, but it overstates fleet urgency for most enterprises. Real-world exploitation is narrowed by multiple gates: you need the uncommon ksmbd server rather than ordinary Samba, you need reachable SMB service on TCP/445, you likely need a valid SMB session to drive the replay path, and the outcome is an availability leak rather than direct code execution or privilege escalation. On a 10,000-host estate, this is a targeted file-server hygiene issue, not a broad emergency.

Why this verdict

• Downward pressure: requires ksmbd, not generic Linux. The vulnerable component is the kernel SMB server path, which is a much smaller population than 'all Linux hosts'.
• Downward pressure: attacker position is already narrowed. You need network reachability to a ksmbd file server and, in realistic deployments, valid SMB access or equivalent protocol state to drive the replay path.
• Downward pressure: impact is availability leakage, not takeover. The patch fixes a leaked reference on an error path; that can hurt service stability, but it does not hand over code execution, privilege escalation, or data exfiltration by itself.

Why not higher?

There is no KEV listing, no reviewed public exploitation evidence, and no public PoC raising attacker reliability. More importantly, the reachable population is constrained twice over: first to hosts that run ksmbd, then to a feature-specific durable-handle replay path with availability-only impact.

Why not lower?

This is still kernel-space code on a file server, so a tenant or user with SMB access can potentially degrade a production service that the business depends on. If you intentionally deploy ksmbd on internal storage or edge appliances, the issue is real enough to fix rather than dismiss.

1. Inventory ksmbd now — Identify hosts with the ksmbd module present, built-in, or loaded, and correlate them with listeners on 445/tcp. For a LOW verdict there is no SLA; treat as backlog hygiene, but you cannot prioritize what you have not inventoried.
2. Restrict SMB reachability — Limit 445/tcp to approved admin, user, or application subnets so arbitrary east-west access cannot hammer the service. For LOW, there is no SLA; treat as backlog hygiene, but exposed file servers should still be tightened during the next firewall review.
3. Prefer userspace Samba where feasible — If ksmbd is not a hard requirement, standardize on the better-understood userspace stack and unload/blacklist ksmbd on nonessential hosts. For LOW, there is no SLA; treat as backlog hygiene.
4. Monitor ksmbd health — Alert on ksmbd-related kernel log entries, sudden memory pressure, and abnormal SMB error/replay patterns so repeated leak attempts show up before the service falls over. For LOW, there is no SLA; treat as backlog hygiene.

Run this on the target Linux host as root or with enough privilege to read kernel config, module metadata, and socket state. Save it as check-cve-2025-71204.sh and run sudo bash check-cve-2025-71204.sh; it will print VULNERABLE, PATCHED, or UNKNOWN based on upstream version ranges plus whether ksmbd appears enabled/active.

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

set -u

KVER_RAW="$(uname -r)"
KVER="${KVER_RAW%%-*}"
RC_TAG=""
if [[ "$KVER_RAW" =~ -rc([0-9]+) ]]; then
  RC_TAG="rc${BASH_REMATCH[1]}"
fi

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

ver_ge() {
  # returns 0 if $1 >= $2
  [[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" == "$1" ]]
}

ver_lt() {
  # returns 0 if $1 < $2
  [[ "$1" != "$2" ]] && [[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" == "$1" ]]
}

version_in_range() {
  local v="$1" start="$2" end_excl="$3"
  ver_ge "$v" "$start" && ver_lt "$v" "$end_excl"
}

is_vulnerable_upstream_version() {
  local v="$1"

  # Explicit rc handling for 6.19-rc1..rc3
  if [[ "$v" == "6.19" && -n "$RC_TAG" ]]; then
    case "$RC_TAG" in
      rc1|rc2|rc3) return 0 ;;
    esac
  fi

  version_in_range "$v" "6.6.32" "6.6.124" && return 0
  version_in_range "$v" "6.9" "6.12.70" && return 0
  version_in_range "$v" "6.13" "6.18.10" && return 0

  return 1
}

is_fixed_or_unaffected_upstream_version() {
  local v="$1"

  # Pre-6.6.32 and 6.6.124+/6.12.70+/6.18.10+/6.19+ are upstream-safe by published ranges.
  if ver_lt "$v" "6.6.32"; then
    return 0
  fi

  if ver_ge "$v" "6.19"; then
    # Non-RC 6.19+ considered fixed by upstream record.
    [[ -z "$RC_TAG" ]] && return 0
  fi

  if version_in_range "$v" "6.6.124" "6.9"; then
    return 0
  fi

  if version_in_range "$v" "6.12.70" "6.13"; then
    return 0
  fi

  if version_in_range "$v" "6.18.10" "6.19"; then
    return 0
  fi

  return 1
}

ksmbd_present="no"
ksmbd_loaded="no"
ksmbd_listening="no"
ksmbd_built_in="no"

if lsmod 2>/dev/null | awk '{print $1}' | grep -qx 'ksmbd'; then
  ksmbd_loaded="yes"
fi

if [[ -e /sys/module/ksmbd ]]; then
  ksmbd_present="yes"
fi

if [[ -f "/lib/modules/${KVER_RAW}/modules.builtin" ]] && grep -q '/ksmbd\.ko' "/lib/modules/${KVER_RAW}/modules.builtin"; then
  ksmbd_built_in="yes"
  ksmbd_present="yes"
fi

if [[ -f "/boot/config-${KVER_RAW}" ]] && grep -q '^CONFIG_SMB_SERVER=y' "/boot/config-${KVER_RAW}"; then
  ksmbd_built_in="yes"
  ksmbd_present="yes"
fi

if [[ -f "/boot/config-${KVER_RAW}" ]] && grep -q '^CONFIG_SMB_SERVER=m' "/boot/config-${KVER_RAW}"; then
  ksmbd_present="yes"
fi

if have_cmd ss; then
  if ss -ltnp 2>/dev/null | grep -E 'LISTEN.+:445\b' | grep -qi 'ksmbd\|mountd'; then
    ksmbd_listening="yes"
  fi
fi

# Heuristic note for distro backports
backport_hint="no"
if [[ -f /etc/os-release ]]; then
  . /etc/os-release
  case "${ID:-}:${ID_LIKE:-}" in
    debian:*|ubuntu:*|rhel:*|fedora:*|sles:*|opensuse:*) backport_hint="yes" ;;
  esac
fi

if is_fixed_or_unaffected_upstream_version "$KVER"; then
  echo "PATCHED"
  exit 0
fi

if is_vulnerable_upstream_version "$KVER"; then
  # Strong vulnerable signal only when ksmbd is active/present.
  if [[ "$ksmbd_loaded" == "yes" || "$ksmbd_built_in" == "yes" || "$ksmbd_listening" == "yes" ]]; then
    echo "VULNERABLE"
    exit 1
  fi

  # Kernel version is in-range, but ksmbd does not appear active. Also backports may apply.
  echo "UNKNOWN"
  exit 2
fi

# Anything else is ambiguous: vendor backports, custom kernels, or unparsable versioning.
echo "UNKNOWN"
exit 2

Sources

1. NVD CVE-2025-71204
2. OpenCVE record for CVE-2025-71204
3. Linux kernel docs: KSMBD - SMB3 Kernel Server
4. Debian security tracker: CVE-2025-71204
5. Oracle Linux CVE page
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS data and statistics
8. Snyk vulnerability entry with EPSS percentile context