CVE-2026-31478

What it actually does

This is a remotely reachable memory-corruption flaw in the Linux kernel ksmbd SMB server. The vulnerable code calculates an SMB2 response output buffer length using an incorrect hardcoded header length after ksmbd changed to dynamic I/O vector response handling for SMB2 read compound operations. When ksmbd processes specially crafted SMB2 traffic, the wrong offset can cause incorrect response-buffer sizing and memory handling in kernel context. Because ksmbd runs in the kernel, successful exploitation can plausibly result in kernel memory corruption with high-impact outcomes: denial of service through kernel crash, information disclosure, or arbitrary code execution with kernel privileges. The CVSS vector indicates network access, low attack complexity, no authentication, and no user interaction are required.

Why it matters to the business

Systems exposing the Linux kernel ksmbd SMB service may be vulnerable to remote compromise or outage from unauthenticated network traffic. Operationally, this can disrupt file sharing, crash affected servers, expose sensitive data stored on SMB shares, or give an attacker a foothold with very high privileges. Although EPSS is currently low and there is no known CISA KEV listing or public exploit maturity reported, the CVSS score is critical and the attack surface is network-facing, so internet-exposed or broadly reachable SMB services should be treated as high priority.

How an attack unfolds

An attacker first identifies a host exposing SMB over the network, typically TCP port 445, and determines that the service is provided by Linux ksmbd rather than a userspace SMB implementation. The attacker then sends crafted SMB2 requests, likely involving compound read behavior, that reach the affected buffer-length calculation path in ksmbd. Because the function uses an incorrect header offset for the response structure, ksmbd may allocate or manage the response buffer incorrectly. The resulting memory corruption occurs inside the Linux kernel. Depending on kernel configuration, mitigations, and exploit reliability, this may cause an immediate kernel oops or panic, leak kernel memory through malformed responses, or be shaped into execution of attacker-controlled code in kernel context. Post-exploitation, an attacker with kernel-level execution could disable security controls, access files served by SMB, pivot locally, or establish persistence using standard Linux post-compromise techniques.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the ksmbd fix replacing hardcoded hdr2_len values with the correct offsetof() value in smb2_calc_max_out_buf_len() call sites. No exact fixed package versions were provided in the input, so use the relevant distribution or kernel vendor advisory to identify the first fixed kernel for each platform. If immediate patching is not possible, disable ksmbd, unload or prevent loading of the ksmbd kernel module, and stop any ksmbd service. Restrict SMB exposure to trusted networks only, block inbound TCP/445 and TCP/139 from untrusted networks, and prefer a patched userspace SMB implementation where operationally feasible. Kernel live patching may be acceptable only if the vendor explicitly states that this specific ksmbd fix is covered.

How to confirm the fix worked

Confirm whether ksmbd is enabled or loaded by checking for the ksmbd kernel module and service state, and verify whether TCP/445 is reachable from untrusted networks. Validate remediation by confirming the running kernel build includes the upstream or vendor patch for smb2_calc_max_out_buf_len() call sites using offsetof() rather than hardcoded response header lengths. Where source or debug symbols are available, review the ksmbd SMB2 response handling code path or vendor changelog for the specific ksmbd fix. After patching or disabling ksmbd, rescan exposed hosts to ensure SMB is no longer served by vulnerable ksmbd or is no longer reachable from untrusted networks. Also confirm the system has been rebooted into the fixed kernel if the update was not live-applied.

Typical attack path

1. Scan for hosts exposing SMB, usually TCP/445, and identify Linux ksmbd as the SMB implementation.
2. Establish an SMB2 session or send SMB2 negotiation/session traffic sufficient to reach ksmbd request handling.
3. Send crafted SMB2 compound read requests that trigger the vulnerable response-buffer length calculation path.
4. Cause kernel memory corruption through incorrect response buffer sizing or I/O vector handling.
5. Observe crash behavior for denial of service, or refine the payload to leak memory or gain kernel-level execution.
6. If code execution is achieved, perform post-exploitation actions such as credential access, data theft from SMB shares, defense evasion, or lateral movement.

How to detect it

To assess prior exploitation, review kernel and system logs for ksmbd-related crashes, memory-safety warnings, and unexpected reboots around periods of SMB exposure. Useful sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, crash dumps, kdump/vmcore artifacts, EDR kernel telemetry, firewall logs, NetFlow, packet captures, and SMB server logs if enabled. Look for kernel oops, panic, general protection fault, slab corruption, KASAN, UBSAN, or BUG messages mentioning ksmbd, smb2_calc_max_out_buf_len, smb2_read, compound read handling, or SMB2 response buffer handling. Network detection should focus on unauthenticated or anomalous SMB2 activity, repeated SMB2 compound read requests, malformed SMB2 read packets, abnormal session setup failures followed by crashes, and SMB traffic from unusual sources. Absence of these artifacts does not prove non-exploitation because successful kernel exploitation may leave limited logs, especially if the attacker gains kernel-level control.

• ksmbd
• smb2_calc_max_out_buf_len
• smb2_read
• SMB2 READ
• compound read
• kernel BUG
• Kernel panic
• general protection fault
• Oops:
• KASAN:
• UBSAN:
• slab-out-of-bounds
• use-after-free
• invalid opcode
• RIP: 0010:ksmbd
• RIP: 0010:smb2_calc_max_out_buf_len
• RIP: 0010:smb2_read
• TCP/445
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/modules
• ksmbd.ko

What your security team should do

• Inventory Linux systems exposing SMB and identify which ones use kernel ksmbd.
• Prioritize patching or disabling ksmbd on internet-facing systems and systems reachable from untrusted or large internal networks.
• Block or tightly restrict inbound SMB traffic, especially TCP/445, at network boundaries and between security zones.
• Monitor kernel logs and SIEM telemetry for ksmbd crashes, KASAN reports, kernel oops messages, or unusual SMB2 compound read traffic.
• If any affected system shows unexplained ksmbd-related kernel crashes or malformed SMB traffic, treat it as potentially compromised and perform forensic triage before returning it to service.
• Track vendor advisories for exact fixed kernel package versions and ensure systems reboot into the corrected kernel.
• Because EPSS is currently low and there is no KEV listing, balance urgency with exposure: externally reachable ksmbd should be remediated immediately; isolated systems should follow accelerated kernel patch cycles.