CVE-2026-64389

What it actually does

The flaw is in the Linux kernel ksmbd SMB server's NTLMv2 authentication handling for SMB3 multichannel binding. ksmbd derives and writes a session key into an existing session before validating the NTLMv2 proof, and then can continue processing KEY_XCH even after authentication fails. A remote client can send a crafted SMB session setup binding request with an invalid NTLMv2 proof and key exchange data, causing the session key for an existing SMB session to be modified before STATUS_LOGON_FAILURE is returned. The primary impact is disruption of existing SMB sessions and service availability; limited integrity impact may occur because authentication state is altered incorrectly, but the vulnerability does not indicate direct disclosure of file contents or unauthenticated file access.

Why it matters to the business

Organizations using the in-kernel Linux SMB server may experience remote disruption of file sharing services without the attacker needing valid credentials. Exploitation can break active SMB sessions, interrupt access to shared files, affect applications that depend on SMB storage, and potentially cause operational outages for file servers, embedded appliances, NAS-like systems, or Linux servers exposing TCP/445. The CVSS score is high due to network reachability, low attack complexity, and high availability impact. It is not currently listed in CISA KEV, has no known exploit maturity in the provided data, and has a low EPSS score, but internet-exposed SMB services should still be treated as higher priority because SMB is commonly scanned and abused.

How an attack unfolds

An attacker first reaches a Linux system running ksmbd over SMB, typically TCP/445. The attacker establishes or targets SMB3 session setup behavior involving multichannel binding. They then send an NTLMSSP authentication blob containing an invalid NTLMv2 proof together with KEY_XCH data. Due to the vulnerable code path, ksmbd derives and updates the session key before confirming that the NTLMv2 response is valid. Even though authentication ultimately fails and STATUS_LOGON_FAILURE is returned, the existing bound session may retain the modified session key because the binding error path does not expire the session. As a result, legitimate SMB traffic associated with that session can fail cryptographic validation or otherwise become unusable, producing session disruption and potential service instability.

How to fix it

Apply a vendor kernel update containing the ksmbd fix. The corrected behavior derives the base session key into a local buffer, copies it to sess->sess_key only after the NTLMv2 proof validates, and stops processing KEY_XCH after authentication failure. No exact fixed package versions were provided, so use the security advisories from the relevant Linux distribution, kernel vendor, appliance vendor, or managed image provider. If immediate patching is not possible, reduce exposure by disabling ksmbd where it is not required, blocking untrusted access to TCP/445, limiting SMB access to trusted networks or VPNs, and disabling SMB3 multichannel support if supported and operationally acceptable. Consider using a fully patched alternative SMB implementation if ksmbd is not mandatory.

How to confirm the fix worked

Confirm whether the system uses ksmbd rather than only user-space Samba. Check for loaded ksmbd kernel modules, active ksmbd services, and listeners on TCP/445. Validate that the running kernel package includes the vendor fix for this issue by comparing the installed kernel build to the vendor security advisory or changelog. Where safe and authorized, use a lab reproduction or SMB protocol test to verify that a malformed NTLMv2 SMB3 multichannel binding request fails without changing the session key or disrupting an established session. Also confirm that TCP/445 is not reachable from untrusted networks unless explicitly required.

Typical attack path

1. Identify a Linux host exposing SMB service, usually on TCP/445, backed by the kernel ksmbd server.
2. Negotiate SMB2/SMB3 capabilities and interact with session setup functionality.
3. Use SMB3 multichannel binding behavior against an existing or targeted session context.
4. Send a crafted NTLMSSP_AUTH message with an invalid NTLMv2 proof and KEY_XCH data.
5. Trigger ksmbd to update sess->sess_key before the NTLMv2 proof validation failure is fully handled.
6. Receive STATUS_LOGON_FAILURE while the server-side binding session is not expired.
7. Cause existing SMB sessions to fail, disconnect, or become unable to access shares reliably.

How to detect it

Look for evidence of failed SMB authentication attempts involving SMB3 multichannel binding and NTLMSSP key exchange, especially when followed by unexpected SMB session drops, share access failures, ksmbd instability, or user reports of disconnected file shares. Useful sources include firewall and flow logs for TCP/445, packet captures, Zeek or similar SMB/NTLM protocol metadata, IDS/IPS alerts, Linux kernel logs, systemd journal entries for ksmbd-related services, ksmbd-tools logs if enabled, and endpoint telemetry showing ksmbd module activity or restarts. Network analysis should focus on SMB2/SMB3 SESSION_SETUP requests with NTLMSSP_AUTH, invalid NTLMv2 authentication results, KEY_XCH/key exchange fields, and STATUS_LOGON_FAILURE responses occurring repeatedly from the same source. Host analysis should look for time-correlated ksmbd authentication failures, session disconnects, kernel warnings, service restarts, or client complaints immediately after malformed SMB session setup traffic. Because this issue may not leave a distinctive file artifact, packet-level evidence and authentication/session telemetry are the most reliable sources.

• TCP/445
• ksmbd
• ksmbd.mountd
• SMB2 SESSION_SETUP
• SMB3 multichannel
• NTLMSSP_AUTH
• KEY_XCH
• STATUS_LOGON_FAILURE
• sess->sess_key
• /sys/module/ksmbd
• /proc/modules:ksmbd
• journalctl -k | grep -i ksmbd
• dmesg | grep -i ksmbd

What your security team should do

• Inventory Linux systems, appliances, containers, and embedded devices exposing SMB services and determine whether they use ksmbd.
• Prioritize patching internet-facing or broadly reachable ksmbd servers even though KEV status is false and EPSS is currently low.
• Restrict TCP/445 to trusted clients, management networks, or VPNs; block it at internet and inter-segment boundaries wherever possible.
• Temporarily disable ksmbd or SMB3 multichannel support where business requirements allow until patched.
• Monitor for repeated SMB session setup failures, NTLMSSP authentication failures, and SMB3 multichannel binding attempts from unusual sources.
• Review kernel logs, ksmbd service logs, and network telemetry for signs of SMB session disruption around failed authentication attempts.
• After patching, reboot into the fixed kernel and verify the vulnerable kernel is no longer running.