Technical reports describing several unpatched Linux-related security flaws appeared on public mailing lists in October, exposing implementation details before fixes were ready for general deployment. The most urgent findings are two CVSS 9.0 vulnerabilities in KSMBD, the SMB file server implemented inside the Linux kernel, that could lead to remote code execution.

The reports were submitted through Trend Micro’s Zero Day Initiative and credit an artificial-intelligence scanner with finding the defects. Linux maintainer Greg Kroah-Hartman questioned why submissions without patches were routed to public lists. Reporting on the incident also points to kernel guidance treating AI-discovered bugs as already public, leaving the exact reason for the disclosure route unclear.

Two critical bugs affect the in-kernel SMB server

The first critical report, ZDI-CAN-33774, describes a race condition in KSMBD. A race occurs when concurrent operations interact in an unsafe order. Here, inconsistent handling of queued network requests may cause memory to be read or written beyond its intended boundary, potentially giving a remote attacker a route to execute code.

ZDI-CAN-33549, also rated 9.0, affects KSMBD’s SMB Direct functionality. An integer underflow can occur when a size calculation wraps after subtraction, producing an invalid length that is later used in a memory operation. The flaw concerns SMB Direct over RDMA networking, so systems not using that feature have a different exposure profile.

Neither finding should be confused with Samba. KSMBD is an optional kernel component, whereas Samba is a separate user-space implementation commonly used for file sharing. A Linux host running Samba alone is not automatically affected by these KSMBD reports. Administrators need to check what service and modules their systems actually use.

Public details arrived ahead of broad patches

At the time of reporting, neither critical issue had a CVE identifier or a named correction in the mainline kernel and its integration tree. A change addressing the SMB Direct issue was reportedly present in development work intended for Linux 7.5, but code in a development branch is not equivalent to a patch shipped by stable kernels or Linux distributions.

This gap matters operationally. Kernel changes must be reviewed, merged, backported where appropriate, packaged by distributions, and installed by customers. Public technical information can help defenders identify affected configurations, yet it can also shorten the time attackers need to study a weakness while users still lack a supported update.

Four additional reports broaden the scope

Other disclosures cover unrelated components and impacts. ZDI-CAN-33367 concerns skb_zerocopy networking code and may allow local privilege escalation. ZDI-CAN-34068 describes an out-of-bounds write in the VMware graphics driver with a similar local elevation risk. ZDI-CAN-34076 involves an uninitialized resource in the NVMe over Fabrics target and may disclose information.

ZDI-CAN-32005 is a stack-buffer overflow in ConnMan’s processing of search-domain TCP queries. ConnMan is a network-management service rather than a Linux kernel component, so grouping every report under “kernel flaws” would be inaccurate. Each item needs its own configuration and package assessment.

Risk reduction while fixes are pending

Operators should first determine whether KSMBD is loaded, configured, and reachable. If the service is unnecessary, disabling it removes the immediate exposure to the two remote-code-execution reports. Where it is required, access should be limited to trusted networks, SMB Direct should be evaluated separately, and file-sharing activity should receive heightened monitoring.

• Follow the security advisories issued by the system’s Linux distribution.
• Do not assume a development-branch fix is present in a production kernel.
• Restrict SMB services from untrusted networks and review share permissions.
• Inventory ConnMan, VMware graphics, and NVMe-oF use independently.

Temporary exposure reduction cannot replace a vendor-approved update. Once distributions publish corrected kernels or packages, teams should test and deploy them promptly, accounting for the reboot typically required to activate a new kernel. Until then, precise inventory and network containment are more useful than treating every Linux system as equally vulnerable.