Cloudanix VulnDB

CVE-2026-43185

Critical · 9.8

CVSS

9.8

EPSS

0.8%

Published

May 6, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in Linux file-sharing servers could let an unauthenticated attacker crash the system or possibly take control if the service is reachable over the network.

Wormable
Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

This is a remotely reachable heap buffer overflow in the Linux kernel ksmbd SMB server implementation, specifically in SMB Direct negotiation handling. The vulnerable code incorrectly treats unsigned 32-bit size values as signed integers when calculating the negotiated receive size. A malicious client can supply a crafted preferred send size that is interpreted as smaller than the server maximum, causing ksmbd to accept an invalid maximum receive size. A subsequent oversized SMB Direct message can then write beyond the allocated heap buffer. Because ksmbd runs in kernel context, successful exploitation may allow denial of service through kernel crash and may potentially enable kernel-level code execution, privilege escalation, or data exposure depending on kernel configuration and exploit reliability.

Why it matters to the business

Organizations running affected Linux kernels with ksmbd exposed may face high-impact compromise of file-sharing infrastructure. A remote unauthenticated attacker could crash the server or potentially gain kernel-level control, affecting confidentiality, integrity, and availability of files and systems using kernel SMB services. Although EPSS is currently low and there is no known CISA KEV listing or public exploit maturity reported, the CVSS severity is critical because exploitation requires network access only and no credentials or user interaction. Systems exposing SMB or SMB Direct to untrusted networks carry the highest operational risk.

How an attack unfolds

An attacker first identifies a Linux host running the in-kernel ksmbd SMB server with SMB Direct/RDMA functionality reachable over the network. The attacker initiates SMB Direct negotiation and sends a crafted negotiation value for the preferred send size that abuses the signedness conversion in smb_direct_prepare_negotiation(). The server incorrectly accepts an attacker-controlled receive-size boundary. The attacker then sends a follow-on SMB Direct message larger than the buffer size ksmbd prepared for the connection. This causes a heap buffer overflow in kernel memory. Depending on system hardening, memory layout, and exploit quality, the result may range from a kernel panic and service outage to more serious kernel memory corruption that could be chained into remote code execution.

How to fix it

Upgrade to a Linux kernel version that includes the ksmbd fix replacing the signed min_t(int, ...) calculation with unsigned min_t(u32) handling in smb_direct_prepare_negotiation(). If vendor-specific fixed versions are not yet available, apply the relevant distribution kernel security update as soon as it is released. Where immediate patching is not possible, disable ksmbd if it is not required, disable SMB Direct/RDMA exposure where feasible, restrict SMB access to trusted management and client networks, and block inbound SMB-related traffic from untrusted networks. Do not rely on authentication as the primary control because the vulnerability is reachable before credentials are required. If file sharing is required, consider temporarily using a patched user-space SMB implementation or isolating the affected service behind strict network controls until patched.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for CVE-2026-43185 or the upstream ksmbd signedness correction in smb_direct_prepare_negotiation(). Verify whether ksmbd is loaded or active using kernel module and service checks, and confirm whether SMB and SMB Direct/RDMA listeners are reachable from untrusted networks. Validate firewall rules and segmentation by testing that SMB access is only possible from approved subnets. After patching, reboot into the fixed kernel and verify the active kernel version, not only the installed package version. If vulnerability scanners are used, ensure they check the running kernel build and distribution backport status rather than relying only on upstream version strings.

Typical attack path

  1. Scan for Linux systems exposing SMB services, especially ksmbd rather than user-space Samba.
  2. Identify whether SMB Direct/RDMA negotiation is reachable from the attacker’s network path.
  3. Open a connection to the SMB Direct negotiation endpoint.
  4. Send a crafted negotiation request containing an abnormal preferred send size that triggers the signedness error.
  5. Send a second oversized SMB Direct message after negotiation completes incorrectly.
  6. Cause heap memory corruption in the kernel, leading to crash, denial of service, or potential code execution.
  7. Optionally repeat against clustered or redundant file servers to disrupt file-sharing availability.

How to detect it

Look for evidence of abnormal ksmbd activity, kernel memory corruption, or repeated SMB Direct negotiation failures. Useful sources include kernel logs, system journal logs, crash dumps, kdump/vmcore artifacts, audit logs, firewall or flow logs, IDS/IPS telemetry, and EDR records for kernel crashes or unexpected reboots. Investigate kernel messages referencing ksmbd, SMB Direct, RDMA, heap/slab corruption, general protection faults, KASAN reports, or panics shortly after inbound SMB/RDMA connections. Network telemetry should be reviewed for unexpected connections to SMB services, especially TCP/445 and SMB Direct/RDMA-related traffic such as TCP/5445 where applicable, from untrusted sources. Because exploitation may result only in a crash, absence of a dropped file or user-space process does not rule out exploitation. Correlate suspicious inbound SMB negotiation traffic with kernel oops, service interruption, host reboot, or clustered file-service failover events.

  • ksmbd
  • smb_direct_prepare_negotiation
  • smb_direct
  • SMB Direct
  • TCP/445
  • TCP/5445
  • preferred_send_size
  • 0x80000000
  • BUG: KASAN: slab-out-of-bounds
  • BUG: KASAN: heap-out-of-bounds
  • kernel BUG at
  • general protection fault
  • Oops:
  • Kernel panic
  • slab corruption
  • use-after-free in ksmbd
  • ksmbd:
  • ksmbd_conn_handler_loop
  • ksmbd_rdma
  • rdma_rw_ctx
  • vmcore
  • /proc/fs/ksmbd
  • /sys/module/ksmbd

What your security team should do

  • Prioritize patching internet-facing or broadly reachable Linux SMB servers, especially systems using ksmbd and RDMA/SMB Direct.
  • Inventory hosts with ksmbd enabled or the ksmbd module loaded; many Linux systems use Samba instead, so confirm actual exposure rather than assuming all SMB servers are affected.
  • Restrict inbound SMB access to trusted networks only; block SMB exposure from the internet and untrusted segments.
  • Disable ksmbd or SMB Direct/RDMA if not operationally required until the fixed kernel is deployed.
  • After applying updates, reboot systems into the fixed kernel and verify the active running version.
  • Review kernel logs for crashes, slab corruption, KASAN reports, or ksmbd errors that could indicate attempted exploitation.
  • Increase monitoring around SMB servers for malformed negotiation attempts, unexpected RDMA traffic, service crashes, or repeated reconnect patterns.
  • Because no KEV listing or mature exploit is currently reported, use risk-based prioritization, but treat exposed ksmbd services as critical due to unauthenticated network reachability and kernel-level impact.

The record

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix signededness bug in smb_direct_prepare_negotiation() smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32)

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities