Kernel: memory leak via ksmbd session setup request with unknown ntlmssp message type

CVE-2023-32255 is a memory leak in the Linux kernel's ksmbd in-kernel SMB3 server. When a client sends an SMBv2 SESSION_SETUP request carrying an NTLMSSP blob with an *unknown* message type, ksmbd's smb2_sess_setup() path allocates the user-session structure but fails to free it on the unexpected-type error branch. The flaw is reachable pre-authentication and affects mainline Linux kernels prior to 6.3.2, where commit town fixed the leak. Every malformed setup wastes a small slab allocation; repeated requests eventually exhaust kernel memory and hang or panic the host.

Red Hat and SUSE both rate this MEDIUM/5.3 and that's about right. The vector is correct — network-reachable, no auth, no UI — but the impact is availability-only, and only against the comparatively rare deployment that runs ksmbd (most Linux file servers still run Samba in userspace). The vendor score is honest; we're downgrading further to LOW because the exposed population is tiny and there is no path to RCE or data exposure.

Why this verdict

• Availability-only impact: the CVSS vector explicitly zeros confidentiality and integrity. The worst-case outcome is a kernel OOM on a file server — recoverable by reboot, no lateral pivot.
• Tiny installed base: ksmbd shipped as a kernel module only since 5.15 and is not the default Linux file-sharing stack. The overwhelming majority of Linux SMB servers in enterprise run userspace Samba and are unaffected.
• Role multiplier — file server tier: even on a high-traffic ksmbd file server, the chain ends in *file-service unavailability for that host*, not domain compromise, data egress, or supply-chain pivot. No high-value role (IdP, CA, hypervisor, EDR, CI/CD, backup) runs ksmbd.
• Friction stacking: internet-exposed SMB is independently a perimeter failure; on internal networks, segmentation and SMB rate-limits break the drip loop trivially.
• No exploitation pressure: EPSS 0.45%, not KEV-listed, no public weaponized tooling, no IR reporting after 11 months of public disclosure.

Why not higher?

MEDIUM (vendor baseline) would imply a 30-day mitigation clock is warranted at fleet scale. With ksmbd's near-zero enterprise penetration and the strictly availability-only impact, that clock would burn defender attention for a vuln that cannot escalate beyond a recoverable reboot. No KEV, no PoC weaponization, no role multiplier — none of the upgrade triggers fire.

Why not lower?

IGNORE would be wrong because the bug *is* pre-auth reachable on any host that actually runs ksmbd, and once a defender confirms ksmbd is in use the standard kernel-patch cadence absolutely applies. We keep it on the backlog rather than dismissing it.

1. Inventory ksmbd usage across the Linux fleet — Run lsmod | grep ksmbd and systemctl is-active ksmbd across the fleet via your config-management plane (Ansible, Salt, Puppet) within the next sprint. Most hosts will return nothing — those are out of scope. No mitigation SLA applies at LOW, so this is hygiene-paced.
2. Block TCP/445 at the perimeter (already table stakes) — Confirm edge firewalls and cloud SGs drop inbound 445/tcp. This is standing policy regardless of CVE; verify, do not deploy fresh. Treat as a quarterly attestation item.
3. On confirmed ksmbd hosts, schedule kernel update to distro-patched build — For hosts that *do* run ksmbd, queue the kernel update into your standard monthly patch ring. No emergency rollout — fold into the next maintenance window within the noisgate remediation SLA of 365 days.
4. Enable host memory-pressure alerting on ksmbd file servers — If you can't patch immediately, an alert at 80% kernel slab usage gives you operator warning long before OOM. Wire to Prometheus/Datadog/Splunk and route to the storage on-call.

Run this on each Linux host as root (or via your config-mgmt agent): sudo ./check-cve-2023-32255.sh. It checks whether ksmbd is even present, and if so whether the running kernel is at or above the distro-patched build.

#!/usr/bin/env bash
# check-cve-2023-32255.sh
# Outputs: VULNERABLE | PATCHED | UNKNOWN | NOT_APPLICABLE
set -u

ks_loaded=0
ks_service=0

if lsmod 2>/dev/null | grep -qw ksmbd; then ks_loaded=1; fi
if systemctl is-active --quiet ksmbd 2>/dev/null; then ks_service=1; fi
if [ -e /sys/module/ksmbd ]; then ks_loaded=1; fi

if [ $ks_loaded -eq 0 ] && [ $ks_service -eq 0 ]; then
  echo "NOT_APPLICABLE: ksmbd module not loaded and service inactive"
  exit 0
fi

KVER=$(uname -r)
MAJ=$(echo "$KVER" | cut -d. -f1)
MIN=$(echo "$KVER" | cut -d. -f2)
PATCH=$(echo "$KVER" | cut -d. -f3 | cut -d- -f1)

# Mainline: fixed in 6.3.2
if [ "$MAJ" -gt 6 ] || { [ "$MAJ" -eq 6 ] && [ "$MIN" -gt 3 ]; } || \
   { [ "$MAJ" -eq 6 ] && [ "$MIN" -eq 3 ] && [ "$PATCH" -ge 2 ]; }; then
  echo "PATCHED: kernel $KVER >= 6.3.2 mainline"
  exit 0
fi

# Distro backport detection
if command -v rpm >/dev/null 2>&1; then
  PKG=$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' kernel 2>/dev/null | tail -1)
  case "$PKG" in
    5.14.0-362*|5.14.0-37*|5.14.0-4*|5.14.0-5*) echo "PATCHED: RHEL backport $PKG"; exit 0 ;;
    5.14.21-150500*|5.14.21-1506*) echo "PATCHED: SUSE backport $PKG"; exit 0 ;;
  esac
elif command -v dpkg >/dev/null 2>&1; then
  PKG=$(dpkg -l 'linux-image-*' 2>/dev/null | awk '/^ii/{print $3}' | tail -1)
  echo "UNKNOWN: Debian/Ubuntu kernel $PKG — cross-reference USN/DSA for CVE-2023-32255 fix"
  exit 2
fi

echo "VULNERABLE: ksmbd present on kernel $KVER, no patched build detected"
exit 1

Sources

1. GHSA-3hjh-cjx8-8c83
2. NVD — CVE-2023-32255
3. Red Hat Security Advisory tracker
4. SUSE CVE database
5. Ubuntu CVE tracker
6. Debian Security Tracker
7. Linux ksmbd subsystem documentation
8. CISA KEV catalog