CVE-2026-31537

What it actually does

This Linux kernel SMB server flaw can corrupt the stream of reassembled SMB Direct data-transfer messages when an immediate empty send is triggered. At a technical level, improper handling of send credits in the SMB server path can break message ordering or stream reconstruction, causing the kernel SMB service or related connection handling to fail. The assessed impact is availability only: confidentiality and integrity are not indicated as directly affected, but service disruption or kernel instability may occur depending on workload and configuration.

Why it matters to the business

Systems using the affected Linux kernel SMB server functionality may experience SMB file-sharing disruption, stalled transfers, dropped connections, or service instability. Because this affects kernel-level SMB handling, outages can impact file shares, backup jobs, application workflows, and user access to shared storage. The current exploitation signal is low: EPSS is 0.00121 and flat over 30 days, it is not listed in CISA KEV, there is no known ransomware association, and no public exploit maturity is reported. However, kernel availability flaws should still be remediated during normal patch cycles, especially on systems exposing SMB services or using SMB Direct/RDMA.

How an attack unfolds

An attacker with the required local low-privileged access, or access to the vulnerable SMB server execution path as applicable to the deployment, attempts to trigger SMB server send behavior that causes an immediate empty send during reassembled data transfer handling. The vulnerable kernel code mishandles send credits, allowing the logical stream of reassembled transfer messages to become corrupted. Once the stream state is corrupted, active SMB sessions may fail, transfers may abort, and the SMB service or kernel networking path may become unstable, producing a denial-of-service condition. No evidence in the provided intelligence indicates data theft, privilege escalation, ransomware use, known exploitation in the wild, or a mature public exploit.

How to fix it

Apply a Linux kernel update that includes the upstream fix for this SMB server send-credit handling issue. No exact fixed package versions were provided, so use vendor advisories for the specific distribution, kernel branch, and appliance build to identify the corrected release. Prioritize systems that run the in-kernel SMB server, expose SMB services to untrusted users, support SMB Direct/RDMA, or host business-critical file shares. If immediate patching is not possible, reduce exposure by disabling the in-kernel SMB server where it is not required, restricting SMB access to trusted networks and authenticated users, disabling SMB Direct/RDMA if not needed, and monitoring for repeated SMB session failures or kernel SMB-related errors. Reboot into the patched kernel after installation; simply installing the package is insufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is a vendor release containing the fix. Check kernel version with standard OS tooling such as `uname -a` and compare it against the distribution vendor’s fixed advisory. Verify whether the in-kernel SMB server module or service is enabled, for example by checking loaded kernel modules, SMB service configuration, and active listeners on TCP/445 where applicable. After patching and rebooting, perform functional SMB transfer testing, including large file transfers and concurrent sessions, and confirm there are no new kernel log messages related to SMB server stream corruption, SMB Direct send failures, RDMA transport errors, connection resets, or kernel warnings. For systems where mitigation rather than patching is used, validate that SMB exposure is restricted by firewall rules and that unused SMB server or SMB Direct functionality is disabled.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with the in-kernel SMB server functionality enabled or reachable through the relevant SMB/SMB Direct path.
2. Obtain the required low-privileged local access or otherwise reach the vulnerable SMB server code path in the affected deployment model.
3. Initiate SMB server activity that exercises reassembled data-transfer message handling.
4. Trigger an immediate empty send condition that causes incorrect send-credit handling.
5. Cause corruption of the reassembled transfer stream, leading to failed SMB sessions, aborted transfers, service instability, or denial of service.

How to detect it

To assess possible prior exploitation or attempted triggering, review Linux kernel logs, system journals, SMB server logs, and RDMA/SMB Direct-related logs for abnormal SMB session resets, failed transfers, kernel warnings, connection teardown loops, or service instability around SMB activity. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, distribution-specific SMB server logs, audit logs for local users interacting with SMB-related tooling, and network telemetry for repeated SMB connections or failed large transfers. Look for bursts of SMB failures from the same user, host, or time window, especially if followed by kernel warnings, hung tasks, service restarts, or loss of access to SMB shares. Since no public exploit indicators, malware artifacts, threat actors, or ransomware campaigns are provided, detection should focus on behavioral evidence of availability attacks or stress attempts rather than malware-specific signatures.

• ksmbd
• smbdirect
• SMB Direct
• RDMA
• send_io
• bcredits
• reassembled data transfer
• kernel: ksmbd
• kernel: smbdirect
• CIFS:
• TCP/445
• hung task
• BUG: kernel
• WARNING: CPU
• Oops:
• connection reset by peer
• transport endpoint is not connected
• Broken pipe

What your security team should do

• Inventory Linux systems running SMB server functionality, especially kernel SMB server deployments and systems using SMB Direct/RDMA.
• Prioritize kernel updates for SMB file servers, storage nodes, backup targets, and any systems where SMB service disruption would create operational impact.
• Use vendor kernel advisories to identify the exact fixed version for each Linux distribution or appliance because fixed versions were not provided in the input.
• Ensure patched systems are rebooted into the corrected kernel and verify the running kernel version after reboot.
• Where patching is delayed, restrict SMB access to trusted networks, disable unnecessary SMB server exposure, and disable SMB Direct/RDMA if not required.
• Monitor kernel, system, and SMB service logs for repeated SMB disconnects, transfer failures, kernel warnings, or RDMA/SMB Direct errors.
• Because KEV status is false, ransomware association is false, EPSS is low and flat, and exploit maturity is listed as none, handle this as routine-to-priority patching rather than emergency response unless the affected system is business-critical or internet-exposed.