01 · The Real Story
A faucet that drips a few bytes every time a stranger knocks on the SMB door
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.
"Unauthenticated ksmbd memory leak — slow-drip DoS, but only matters if you actually run ksmbd exposed. Almost nobody does."
02 · The Attack Path
3 steps from start to impact.
STEP 01
Reach an exposed ksmbd listener
Attacker needs TCP/445 reachable to a Linux host running the in-kernel
ksmbd server (CONFIG_SMB_SERVER=y, ksmbd.mountd running). This excludes the dominant Samba (userspace smbd) population entirely.Conditions required:
- Target runs Linux kernel <6.3.2 with ksmbd module loaded
- TCP/445 reachable from attacker network position
Where this breaks in practice:
- ksmbd usage is a rounding error vs. Samba in production fleets
- Internet-exposed SMB is blocked by every competent perimeter; Shodan shows <5k Linux SMB hosts of any flavor
Detection/coverage: Nessus 176700, Qualys QID 757865, OpenSCAP oval:com.redhat.rhsa rules cover kernel versions.
STEP 02
Send malformed NTLMSSP SESSION_SETUP
Using a tweaked impacket
smbclient or a 30-line Python over smbprotocol, the attacker sends an SMB2 SESSION_SETUP request whose security blob is valid GSS-API/NTLMSSP but carries a MessageType field that is neither NEGOTIATE(1), CHALLENGE(2), nor AUTHENTICATE(3). No public weaponized PoC tool is named in advisories; trivial to construct.Conditions required:
- Ability to speak SMB2 wire protocol
- Ability to forge NTLMSSP message header
Where this breaks in practice:
- No drop-in Metasploit/Nuclei module exists
- Per-request leak is bytes-scale; takes sustained traffic to matter
Detection/coverage: Suricata/Zeek SMB anomaly rules flag malformed NTLMSSP types; volumetric SMB to a file server is independently suspicious.
STEP 03
Drip-loop to exhaust kernel slab
Attacker loops the malformed request — thousands to millions of times — to accumulate orphaned
ksmbd_session allocations in kernel slab. Eventually kmalloc fails, oom-killer triggers, or the host hangs. No code execution, no data read, no lateral movement.Conditions required:
- Sustained network access to the listener
- No upstream rate-limit on port 445
Where this breaks in practice:
- IPS, connection-rate limits, fail2ban-style controls trivially break the loop
- Reboot fully restores; no persistence
Detection/coverage: Standard host memory-pressure alerts (Prometheus node_exporter, Datadog, Splunk UF) fire long before exhaustion.
03 · Compensating Control
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.
What doesn't work
- SMB signing / encryption: the leak triggers in session setup *before* the signing context is established; signing policy does not block the malformed NTLMSSP message type.
- Authentication requirements / restrictAnonymous: the bug is reachable pre-auth in the SESSION_SETUP exchange itself; requiring credentials does not gate the vulnerable code path.
- WAF / reverse proxy: SMB is not HTTP; L7 web controls have no visibility into the SMB2 NTLMSSP blob.
- EDR on the file server: the leak is in kernel slab inside the SMB protocol handler — there is no userspace process behavior for EDR to flag until the OOM-killer fires.
04 · Intelligence Metadata
The supporting signals.
| In-the-wild exploitation | None observed. No GreyNoise tag, no vendor IR reporting, no ransomware affiliate use. |
|---|---|
| KEV status | Not listed on CISA KEV as of 2026-07-01. |
| EPSS | 0.00453 (~0.5%) — bottom-quartile likelihood of exploitation in the next 30 days. |
| Public PoC | No weaponized public PoC repo; root-cause patch is in mainline Linux commit fixing smb2_sess_setup() leak. Reachable via impacket with minor protocol tweak. |
| CVSS vector | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L — network, no auth, low availability impact only. No confidentiality or integrity loss. |
| Affected versions | Linux kernels with ksmbd enabled prior to 6.3.2. Backports: RHEL 9.x kernel-5.14.0-362+, SUSE SLE15-SP5 kernel-5.14.21-150500, Ubuntu 22.04 linux-image-5.15.0-91+, Debian 12 linux-6.1.55-1+. |
| Fixed in | Linux 6.3.2 mainline; distro backports per above. |
| Exposure data | Shodan: ~4,300 hosts globally fingerprinting as Linux SMB on 445; ksmbd-specific fingerprint is a subset and uncommon in enterprise. Censys shows similarly thin footprint. |
| Disclosure | GHSA-3hjh-cjx8-8c83 published 2025-08-03; underlying fix landed in mainline May 2023. |
| Reporter | Reported via the Linux kernel ksmbd subsystem maintainers (Namjae Jeon / Steve French upstream). |
Sources.
05 · The Call
Final Verdict
↓ DOWNGRADED to LOW (3.5/10)
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.
06 · Verification
Crowdsourced verification payload.
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