Linux servers running KSMBD, the kernel's built-in SMB server, are currently exposed to two publicly reported remote code execution vulnerabilities, both carrying a CVSS score of 9.0 from Trend Micro's Zero Day Initiative, and because no fix has been integrated into the mainline kernel yet, administrators must rely on manual detection and environmental mitigations to secure their infrastructure.

Technical Analysis of ZDI-CAN-33774

ZDI-CAN-33774 represents the more immediate threat, as it requires no authentication to exploit, exposing any server running KSMBD on port 445, and the vulnerability is a race condition in how KSMBD assigns its handler table, where an attacker can send a burst of short SMB1 packets followed by an SMB2 packet within the same TCP write, which causes the server's workers to process SMB1 data using an SMB2 handler, resulting in a read past the end of the shorter buffer.

Once an attacker gains access to a share, a viable path to writing past the buffer exists, which enables full code execution on the host system.

Technical Analysis of ZDI-CAN-33549

The second vulnerability, ZDI-CAN-33549, requires the SMB Direct transport and an RDMA-capable network interface, and this flaw is an integer underflow in the SMB Direct path, where a client can supply RDMA buffer descriptors in which the first is longer than the declared payload, causing the server's size counter to wrap, and allowing a subsequent memory copy to overrun the end of an allocated buffer.

Exploitation of this specific flaw requires three distinct conditions to be met:

• An RDMA-capable interface, whether that is physical hardware or the rxe software driver.
• A writable KSMBD share that the attacker can target.
• A client negotiating the SMB Direct transport protocol.

The Patching Gap and CVE Absence

As of Thursday, neither flaw has a named fix in the mainline kernel or in linux-next, the integration tree that feeds it, and while Linux news site Phoronix reported that SMB Direct maintainer Stefan Metzmacher submitted a fix for ZDI-CAN-33549 targeting the next kernel development cycle, this has not been independently confirmed.

Fixes to mainline typically take weeks to reach stable branches and distribution kernels, and because the kernel project assigns CVE identifiers only after a stable-tree fix is available, neither flaw currently carries a CVE, which means standard vulnerability scanners will not flag exposed systems.

The AI-Discovered Reporting Controversy

The ZDI reports credit TrendAI, Trend Micro's AI scanner, as the finder, and this attribution follows the Linux kernel's security documentation, updated in May 2026 following guidance from Linus Torvalds, which states that bugs found by AI tools are by definition already public and should be sent to subsystem developer lists.

ZDI's routing appeared to follow that logic, copying public mailing lists alongside the private kernel security address, but they did not attach patches to any of the reports, and stable-kernel maintainer Greg Kroah-Hartman replied to three of the five kernel reports within minutes of each other.

To the report on the VMware GPU driver, he wrote: "For some reason you sent this to public lists, and did not include a patch, so there's not much we can do with this." On the NVMe driver report, seventeen seconds later, he added: "Again, no patch, and sent to a public list? Please fix your submission process."

Additional ZDI Kernel Reports

Three of the five kernel reports are not related to SMB, and these additional findings highlight the broad scope of the recent ZDI submissions:

• ZDI-CAN-33367: Discovered by researcher p1r0x, this is a local privilege escalation in the kernel's networking stack that requires local access.
• ZDI-CAN-34068: A local privilege escalation vulnerability in the VMware virtual GPU driver.
• ZDI-CAN-34076: An information disclosure flaw in the NVMe target driver.

None of these three flaws affect KSMBD servers. A sixth ZDI report, ZDI-CAN-32005, is a buffer overflow in ConnMan, a network daemon separate from the Linux kernel.

Mitigation and Detection Strategies

Because there is no mainline patch, organizations must focus on reducing their attack surface immediately, and administrators can verify the module status by running systemctl status ksmbd or lsmod | grep ksmbd, noting that Red Hat Enterprise Linux does not include KSMBD by default according to Red Hat's support documentation.

Defenders should implement the following critical mitigation steps:

• Disable KSMBD if it is not actively used: If the service is not running, the flaws cannot be reached.
• Enforce strict firewall rules: Block port 445 from external traffic, because SMB should never be exposed directly to the public internet.
• Monitor network logs: Watch for bursts of short SMB1 packets followed by SMB2 packets within a single TCP write, as this sequence matches the ZDI-CAN-33774 attack pattern.
• Review RDMA configurations: If SMB Direct is not a strict operational requirement, disabling RDMA interfaces eliminates the attack surface for ZDI-CAN-33549 entirely.

FAQ

What is KSMBD?

KSMBD is the Linux kernel's built-in SMB server, which handles file sharing and network communication for Linux systems.

What are ZDI-CAN-33774 and ZDI-CAN-33549?

They are two remote code execution flaws in KSMBD, both rated 9.0 by Trend Micro's Zero Day Initiative, with ZDI-CAN-33774 requiring no authentication, while ZDI-CAN-33549 requires SMB Direct and an RDMA-capable interface.

Is there a patch available?

Not yet, as there is no fix in the mainline kernel, and distribution kernels will take additional weeks to incorporate the patch once it is merged.

Why is there no CVE?

The Linux kernel project assigns CVE identifiers only after a fix is available in a stable tree, so until that occurs, the flaws remain without official CVE tracking.

How do I check if my server is vulnerable?

Run systemctl status ksmbd or lsmod | grep ksmbd. If the module is active, you are vulnerable.

Source: The Hacker News