CVE-2026-31536

What it actually does

This is a Linux kernel use-after-free in the SMB server path, specifically the SMB Direct/RDMA send completion handling. Batched SMB Direct send requests may include work requests that are not explicitly marked with IB_SEND_SIGNALED and are expected to be cleaned up by a later signaled request. When the connection breaks, completions can be delivered for all outstanding requests, including those that were not expected to complete individually. The send completion handler can then operate on request state that has already been released, creating a kernel memory-safety condition. Depending on kernel configuration, allocator behavior, and exploit reliability, impact can range from kernel crash and denial of service to potential kernel-level code execution or data corruption.

Why it matters to the business

Systems exposing the Linux kernel SMB server, especially with SMB Direct/RDMA enabled, may be remotely destabilized or potentially compromised without authentication. A successful attack could interrupt file-sharing services, crash affected hosts, corrupt active SMB sessions, or provide an attacker with kernel-level control. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the high CVSS score means internet- or partner-exposed SMB services should still be treated as high priority, particularly for file servers, storage appliances, virtualization hosts, and environments using RDMA-backed SMB workloads.

How an attack unfolds

An attacker targets a Linux host running the in-kernel SMB server with SMB Direct/RDMA support reachable over the network. The attacker establishes or manipulates an SMB Direct connection and causes batched send operations to be queued where some work requests are not individually signaled. The attacker then forces abnormal connection teardown or transport failure so that completions are generated for requests that the kernel code did not expect to complete independently. The vulnerable completion path may process request objects after they have already been destroyed by cleanup associated with another request. This can crash the kernel immediately, or, with precise timing and heap shaping, may allow exploitation of freed kernel memory to influence control flow or corrupt sensitive kernel data.

How to fix it

Upgrade affected Linux kernels to a version that includes the upstream fix for the SMB server SMB Direct send completion handling issue. If a vendor distribution is used, apply the corresponding kernel security update from the distribution or appliance vendor rather than relying only on upstream kernel version numbers. No exact fixed package versions were provided in the input, so administrators should consult their Linux distribution advisories for CVE-2026-31536 and confirm the installed kernel contains the patch that lets the SMB Direct send_done path safely handle completions for requests without IB_SEND_SIGNALED. If immediate patching is not possible, reduce exposure by disabling the in-kernel SMB server if unused, disabling SMB Direct/RDMA where not required, blocking SMB/RDMA access from untrusted networks, restricting SMB service access to trusted management or storage networks, and monitoring for kernel crashes or SMB Direct transport errors.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package is at or above the vendor-fixed version and that the security advisory for CVE-2026-31536 is marked resolved for that package. Reboot into the patched kernel where required, because kernel package installation alone does not protect systems still running an older kernel. Validate exposure by checking whether the in-kernel SMB server is enabled and whether SMB Direct/RDMA modules and services are active. Useful checks include reviewing loaded kernel modules for ksmbd and RDMA components, checking listening SMB ports, reviewing SMB server configuration for RDMA/SMB Direct support, and confirming firewall controls limit access to trusted networks. For high-assurance validation, run a controlled SMB Direct connectivity test after patching and verify no kernel warnings, use-after-free reports, KASAN findings, oops messages, or ksmbd/smbdirect completion errors appear in kernel logs.

Typical attack path

1. Identify Linux systems exposing SMB services, especially hosts using the in-kernel SMB server and RDMA/SMB Direct capabilities.
2. Establish SMB or SMB Direct connectivity to the target service from a reachable network location.
3. Trigger batched SMB Direct send activity that includes unsignaled RDMA send requests.
4. Induce connection failure, reset, or abnormal teardown while outstanding sends are still pending.
5. Cause the completion handler to process send completions for requests that have already been freed or logically consumed.
6. Leverage the resulting use-after-free to crash the host or attempt kernel memory corruption for higher-impact exploitation.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, and SMB server logs for abnormal SMB Direct/RDMA connection teardown followed by kernel memory errors or host crashes. Key sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, pstore records, vmcore/kdump artifacts, netconsole output, and any logs from SMB server or RDMA management tooling. Look for sequences involving ksmbd, SMB Direct, smbdirect send completion handling, RDMA completion errors, connection resets, kernel oops/panic messages, use-after-free diagnostics, KASAN reports, slab allocator corruption, or unexplained reboots. Network telemetry can help identify repeated SMB connections, RDMA connection attempts, or abrupt resets targeting SMB/RDMA-capable hosts. There are no reliable public exploit-specific payload markers in the provided information, so detection should focus on behavioral correlation: inbound SMB/SMB Direct activity from unusual sources, forced disconnect patterns, and immediate kernel instability.

• ksmbd
• smbdirect
• SMB Direct
• IB_SEND_SIGNALED
• send_done
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• slab-use-after-free
• kernel panic
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/fs/pstore
• vmcore
• kdump

What your security team should do

• Prioritize patching Linux systems that expose SMB services or use SMB Direct/RDMA, especially externally reachable file servers, storage nodes, and infrastructure hosts.
• Inventory systems running the in-kernel SMB server and identify which have RDMA-capable networking or SMB Direct enabled.
• Apply vendor kernel updates and reboot into the fixed kernel; track completion separately from package installation status.
• If patching is delayed, disable SMB Direct/RDMA or the in-kernel SMB server where operationally feasible.
• Restrict SMB and RDMA-related traffic to trusted networks using host firewalls, network ACLs, and segmentation.
• Monitor kernel logs for crashes, use-after-free warnings, KASAN reports, ksmbd errors, RDMA completion anomalies, and unexpected SMB connection resets.
• Treat repeated SMB Direct connection failures followed by kernel instability as suspicious and preserve logs, crash dumps, and memory evidence for forensic review.
• Because there is no current KEV listing, ransomware association, or mature public exploit reported, use risk-based prioritization, but do not defer remediation on exposed or critical file-sharing infrastructure.