CVE-2026-31433

What it actually does

This flaw is an out-of-bounds write in the Linux kernel ksmbd SMB server. An authenticated SMB client can send a compound SMB2 request that combines QUERY_DIRECTORY and QUERY_INFO using FILE_ALL_INFORMATION in a way that nearly exhausts the negotiated response buffer. The vulnerable code fails to validate the client-controlled OutputBufferLength before converting and copying a filename into the FILE_ALL_INFORMATION response structure. As a result, ksmbd may write past the end of the allocated SMB response buffer during UTF-16 filename conversion, causing kernel memory corruption. Depending on kernel configuration, allocator state, and exploit reliability, impact can range from ksmbd/kernel crash and denial of service to possible privilege escalation or code execution in kernel context.

Why it matters to the business

Organizations using ksmbd to provide SMB file-sharing services could face file-server outages, corruption of in-memory kernel state, unauthorized access to file server data, or broader host compromise if exploitation is made reliable. Because exploitation is network-accessible but requires valid SMB credentials, risk is highest where untrusted, shared, partner, guest, or low-privileged accounts can connect to ksmbd shares. The issue is not listed in CISA KEV, is not reported as ransomware-used, has no known public exploit maturity in the supplied data, and has a low, stable EPSS score, but the high CVSS impact and kernel-level memory corruption make it important to remediate on exposed SMB servers.

How an attack unfolds

An attacker first obtains any credentials that allow access to a ksmbd-backed SMB service. They then connect over SMB and negotiate parameters including the maximum transaction size. The attacker sends a crafted compound SMB2 request where a QUERY_DIRECTORY operation consumes nearly all available response buffer space, followed by a QUERY_INFO request for FILE_ALL_INFORMATION. The QUERY_INFO portion includes an OutputBufferLength that is too small for the filename data that ksmbd attempts to return. On vulnerable kernels, ksmbd calculates the response incorrectly and calls the UTF-16 conversion routine with an unsafe length, causing the filename copy to write beyond the end of the response buffer. Successful exploitation can crash the kernel or corrupt memory in a way that may allow deeper compromise if the attacker can control memory layout reliably.

How to fix it

Apply a Linux kernel update that contains the ksmbd fix for this issue. The corrected behavior validates available output buffer space using the actual calculated remaining response size and limits the filename conversion length before copying into the FILE_ALL_INFORMATION structure. Because exact fixed package versions were not provided, use the security advisory and kernel packages from the relevant Linux distribution, appliance vendor, or kernel source branch. If immediate patching is not possible, disable ksmbd where it is not required, replace exposure with a patched SMB implementation, restrict SMB access to trusted networks, require strong authentication, remove guest/anonymous access, and limit which low-privileged users can access ksmbd shares. Network controls should block SMB ports, typically TCP/445, from untrusted networks.

How to confirm the fix worked

Confirm whether the host is running ksmbd and whether the installed kernel package includes the vendor fix for this vulnerability. Validate remediation by checking the running kernel version after reboot, confirming the updated kernel package is active rather than merely installed, and reviewing the vendor changelog or source patch for the ksmbd get_file_all_info(), smb2_calc_max_out_buf_len(), or smbConvertToUTF16-related fix. From an exposure perspective, verify that ksmbd is disabled if not needed, that TCP/445 is not reachable from untrusted networks, and that SMB guest or broad low-privileged access is not permitted. For high-assurance validation, use a safe, non-destructive scanner or vendor-provided test that checks for the patched ksmbd behavior without attempting memory corruption.

Typical attack path

1. Identify an SMB service backed by Linux ksmbd rather than user-space Samba.
2. Obtain or reuse valid SMB credentials with access to a share or directory listing capability.
3. Establish an SMB2 session and determine server limits such as maximum transaction size.
4. Send a crafted compound SMB2 request containing QUERY_DIRECTORY followed by QUERY_INFO for FILE_ALL_INFORMATION.
5. Shape the first command so it consumes nearly the entire response buffer and set the second command's output length so the filename field does not fit.
6. Trigger the vulnerable filename UTF-16 conversion path in get_file_all_info().
7. Cause kernel memory corruption, resulting in denial of service or potentially further exploitation depending on system hardening and exploit reliability.

How to detect it

Review network, SMB, endpoint, and kernel telemetry for signs of suspicious authenticated SMB activity against ksmbd. Useful sources include firewall and NetFlow records for TCP/445, SMB server/session logs where available, Linux kernel logs, system journal entries, crash dumps, audit logs, and EDR telemetry. Look for authenticated SMB clients sending unusual compound requests that combine QUERY_DIRECTORY and QUERY_INFO FILE_ALL_INFORMATION, especially when followed by ksmbd errors, kernel warnings, KASAN reports, general protection faults, kernel oops messages, spontaneous reboots, or file-server disruption. Because the vulnerable operation occurs in kernel response construction, successful exploitation may not create a clean application log entry; kernel crash artifacts and timing correlation with SMB sessions are particularly important. If packet capture or network detection is available, search for SMB2 compound chains involving QUERY_DIRECTORY followed immediately by QUERY_INFO where the queried information class is FILE_ALL_INFORMATION and response/output buffer sizes appear unusually small or boundary-sized. Also investigate repeated failed SMB sessions or crashes originating from the same authenticated client account or IP address.

• ksmbd
• get_file_all_info
• smbConvertToUTF16
• smb2_calc_max_out_buf_len
• FILE_ALL_INFORMATION
• QUERY_DIRECTORY
• QUERY_INFO
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG at
• Oops:
• RIP: 0010:smbConvertToUTF16
• RIP: 0010:get_file_all_info
• RIP: 0010:ksmbd
• ksmbd:
• ksmbd.mountd
• TCP/445

What your security team should do

• Prioritize patching Linux systems that run ksmbd and expose SMB services to user populations, partners, VPN users, or other semi-trusted networks.
• Inventory SMB servers and distinguish Linux kernel ksmbd from Samba smbd, since this issue affects ksmbd specifically.
• Disable ksmbd on systems where kernel SMB serving is not required.
• Restrict TCP/445 access to trusted management or client networks and block direct internet exposure.
• Review SMB authentication policy and remove guest, anonymous, stale, shared, or overly broad low-privileged accounts.
• Monitor for kernel crashes, ksmbd faults, SMB compound request anomalies, and repeated QUERY_DIRECTORY plus FILE_ALL_INFORMATION activity from the same client.
• Treat suspicious ksmbd kernel faults as potential security events, not only reliability incidents, because exploitation may leave limited application-layer evidence.
• Because the supplied intelligence shows no KEV listing, no ransomware association, no known exploit maturity, and low stable EPSS, schedule remediation according to normal high-severity kernel maintenance timelines unless ksmbd is externally or broadly exposed.