Two CVSS 9.0 RCE Flaws in Linux KSMBD, No Patch Yet

The SMB server built into the Linux kernel, known as KSMBD, is once again in the spotlight. According to what has leaked on public mailing lists, there are two remote code execution (RCE) vulnerabilities catalogued by Trend Micro's Zero Day Initiative with a CVSS 9.0 score. The detail that should most worry any IT team: there is still no fix in the mainline kernel.

This is not a theoretical advisory or a lab exercise. The flaws have been published before an official solution exists, which opens a real exposure window for any Linux server that has KSMBD active and reachable over the network.

What is known about the two flaws

The available information identifies two different identifiers, with very different exploitation conditions:

• ZDI-CAN-33774: can be triggered before any network authentication. That is, an attacker does not need valid credentials or an established SMB session to attempt to exploit it. This is the classic highest-risk scenario, because it greatly expands the attack surface.
• ZDI-CAN-33549: requires SMB Direct transport and an RDMA-capable network. Its exploitation is more restricted, but no less serious in environments that use this type of high-performance infrastructure.

Both share the same nature: remote code execution. That is, an attacker who manages to exploit them could execute instructions on the affected server, not just read information or cause a denial of service.

Why KSMBD matters more than it seems

KSMBD is the SMB server that lives inside the Linux kernel itself. Its goal is to offer SMB-compatible file sharing without depending on Samba, which in theory simplifies deployment and improves performance. The problem is that, being in the kernel, any flaw of this type has a potentially deeper impact than a user-space service.

In an SME, KSMBD can appear without anyone having explicitly decided so: it comes in many distributions, is sometimes enabled when configuring file shares, and is sometimes left exposed on networks that should not see it. That is the critical point. A flaw that is exploited without authentication on a service that no one knew was running is a dangerous combination.

What it means for your team

Publication on public lists before a patch exists has an immediate consequence: the information is already available to anyone, including those actively looking for vulnerable systems. This is not a silent flaw known only to the vendor. This is a publicly documented flaw with no official remedy at the time of disclosure.

This does not mean you should panic, but it does mean you should act with judgment and without waiting for the update to arrive. Experience with previous episodes, such as PHP2Shell and its emergency patches, shows that the window between disclosure and patch is where incidents concentrate.

Concrete recommendations

The first thing is to know whether you have KSMBD running. Do not assume it: check it. From there, these are the actions we recommend at ForgeNEX:

1. Inventory and verify: review which Linux servers have KSMBD active and whether the service is listening on interfaces accessible from outside the trusted network.
2. Reduce exposure: if you do not need KSMBD, disable it. If you do need it, limit access by firewall to the machines that really must use it. A flaw that is exploited without authentication is largely mitigated by closing the path to it.
3. Segment: the SMB port should not be open to the internet or to guest networks. Review rules and segmentation.
4. Monitor: enable logs and alerts for anomalous access to the service. Without a patch, detection is your main defense.
5. Follow the official channel: stay attentive to kernel updates and apply the patch as soon as it is available in your distribution. Do not wait for the next scheduled maintenance window.

This episode fits a pattern we have been observing: critical flaws that become public before a remedy exists. The lesson is not only technical, but also about process. Having an up-to-date inventory of exposed services and an agile response plan makes the difference between a scare and an incident. As we already discussed when talking about security as a lifecycle, prevention is not a one-off control, but a continuous discipline.

If your SME does not have internal resources for this type of review, perhaps it is time to rely on a partner that can audit exposure and support the response. The window without a patch does not close by itself.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.