The KSMBD module — the built-in SMB server in the Linux kernel — is affected by two remote code execution vulnerabilities, each of which received a CVSS 9.0 score from Trend Micro Zero Day Initiative (ZDI). The more dangerous one, ZDI-CAN-33774, according to available information, can be exploited without authentication on any server with KSMBD listening on port 445. At the time of public disclosure, neither vulnerability had a confirmed fix in the mainline kernel. Administrators of Linux servers with the KSMBD module enabled should immediately check its status and consider temporarily disabling it.
Technical details of the vulnerabilities
ZDI-CAN-33774: unauthenticated handler race condition
According to descriptions from public kernel mailing lists, ZDI-CAN-33774 is a race condition in the KSMBD handler table assignment mechanism. A series of short SMB1 packets followed by an SMB2 packet within a single TCP record causes worker threads to process SMB1 data with an SMB2 handler. This results in reads beyond the bounds of the allocated buffer and, if there is access to a shared folder, potentially writes beyond its boundaries as well. The key risk factor: no authentication is required — network access to port 445 is sufficient.
ZDI-CAN-33549: integer underflow in SMB Direct
ZDI-CAN-33549 is an integer underflow in the SMB Direct processing path. An attacker can pass RDMA buffer descriptors where the first descriptor is longer than the declared payload. This leads to wrapping of the size counter and subsequent buffer overflow when copying data. Exploitation requires three conditions: an RDMA-capable network interface (hardware or the rxe software driver), a KSMBD share with write access, and a client that has negotiated the SMB Direct protocol.
Both CVSS 9.0 scores were assigned by ZDI — there is still no independent confirmation of these scores through CVE entries, since neither vulnerability has been assigned a CVE identifier. According to the Linux kernel CVE process documentation, CVEs are automatically assigned after a fix appears in the stable branch, although a request can be submitted before that moment. Affected kernel versions are not specified in the available materials.
Differences in threat level
Despite having the same CVSS score, the two vulnerabilities differ significantly in their attack surface. ZDI-CAN-33774 threatens any server with KSMBD enabled on port 445 — without requiring authentication and without specific hardware requirements. ZDI-CAN-33549 requires an RDMA infrastructure, which limits its applicability mainly to high-performance computing environments and data centers with SMB Direct support. When planning a response, priority should be given to servers accessible via SMB without additional conditions.
Status of fixes and vendor response
As of October 22, 2026, neither vulnerability had a confirmed fix in the mainline kernel or in the integration branch linux-next. According to a Phoronix report, SMB Direct maintainer Stefan Metzmacher prepared a patch for ZDI-CAN-33549 intended for the next kernel development cycle, but this has not been confirmed by other sources. Even after a fix lands in the mainline tree, it usually takes weeks before it reaches stable branches and distribution kernels.
Red Hat has confirmed that its products are not affected: the KSMBD module is not included in any Red Hat Enterprise Linux release, and the kernel parameters CONFIG_SMB_SERVER_SMBDIRECT and CONFIG_RDMA_RXE are disabled by default. However, this conclusion cannot be generalized to other Linux distributions — each may have its own module configuration. Previously, we already wrote about Linux kernel vulnerabilities that made it into the CISA KEV catalog — the KSMBD situation underscores that critical kernel security issues continue to be discovered in various subsystems.
Public disclosure and procedural conflict
The disclosure method deserves separate attention. ZDI’s reports were sent simultaneously to public kernel mailing lists and to the private security address — without any patches attached. Stable branch maintainer Greg Kroah-Hartman, in his responses to related reports (on the VMware GPU driver and NVMe), directly pointed out the problem: “You sent this to the public lists and did not include a patch, so there is little we can do about it.”
This routing appears to be based on the updated kernel documentation on handling security bugs, according to which vulnerabilities discovered by AI-based tools are by definition not secret and may be sent to public subsystem mailing lists. ZDI cited TrendAI — Trend Micro’s AI-based scanner — as the detection tool, although in the ZDI listing both KSMBD vulnerabilities are attributed to researcher Hyeontae Lee. The connection between the general AI-discovery guidelines and ZDI’s specific decision to route these reports in this way remains speculative.
Practical recommendations
- Check for the module: run
systemctl status ksmbdorlsmod | grep ksmbdto determine whether the module is active on your servers. - Temporary disabling: if KSMBD is not critically needed, disable the module and block inbound traffic to port 445 until an official patch is released.
- Network segmentation: for servers where KSMBD is required, restrict access to port 445 to trusted network segments only — this reduces the risk of exploiting ZDI-CAN-33774, which does not require authentication.
- Assess RDMA configuration: check whether CONFIG_SMB_SERVER_SMBDIRECT and CONFIG_RDMA_RXE are enabled. Disabling them eliminates the ZDI-CAN-33549 attack vector.
- Monitor updates: keep track of patches appearing in the mainline kernel and in the stable branches of your distribution.
The lack of confirmed patches in the mainline kernel at the moment when technical details were publicly disclosed creates a window of elevated risk. There is no information about active exploitation in the available materials, but public availability of the attack mechanics makes exploit development a matter of time. The top-priority action is to check the status of the KSMBD module on all Linux servers and disable it wherever it is not in use, without waiting for an official fix.
