CVE-2026-64578 addresses an out-of-bounds read in Linux’s in-kernel SMB server, ksmbd, when it processes a malformed compound SMB2 request. The practical action is for administrators running ksmbd to move to a kernel containing the upstream fix; Windows clients, Windows Server’s own SMB service, and ordinary Linux SMB clients are not the affected component.

Microsoft’s Security Update Guide published the CVE record on August 9, 2026, but the primary technical record is in the Linux kernel tree: a ksmbd patch authored by Xiang Mei of Microsoft was merged by Linus Torvalds on July 17 for the Linux 7.2 development cycle. That distinction is important because the Microsoft-hosted CVE page can look like a Windows security bulletin at a glance. It is not evidence of a Windows KB, a Windows Server cumulative update, or a flaw in the SMB client built into Windows.

The issue sits in

fs/ksmbd/smb2misc.c

, inside the validation path for SMB2 messages. A remote client can send several SMB2 commands in one network packet, with each command’s

NextCommand

field defining where the next request element begins. Before this fix, ksmbd could advance to a subsequent element and read its

StructureSize2

field without first confirming that the element was long enough to contain that two-byte field.

A truncated request can therefore make the kernel server read beyond the declared bounds of that SMB2 command. The patch adds the missing length check before

StructureSize2

is examined, rejecting an element that does not contain the required field instead of treating it as a normal request.

Cybersecurity infographic showing a Linux SMB3 bounds-check patch blocking malformed SMB2 compound requests.The flaw is in the Linux SMB server, not Windows SMB​

ksmbd is Linux’s SMB3 server implementation, operating in kernel space. It is enabled by the

ksmbd

kernel module and normally paired with the separate

ksmbd-tools

userspace management utilities. It listens for SMB clients over TCP, most commonly on port 445, and can serve Windows, macOS, and Linux clients.

That architecture changes the risk calculation. A malformed packet reaches code executing in the kernel, not a conventional userspace daemon such as Samba’s

smbd

. A crash in a userspace file server can disrupt shares and require a service restart; a memory-safety failure in a kernel protocol handler can destabilize the host itself.

The available upstream description supports an out-of-bounds read caused by invalid packet length handling. It does not establish remote code execution, data disclosure, authentication bypass, or a known exploit. Administrators should resist converting “kernel SMB parsing bug” into a claim of full server compromise without an advisory, proof of concept, or technical analysis showing that outcome.

The exposure is also narrower than a broad “Linux SMB vulnerability” label suggests. A Linux device is relevant only if ksmbd is enabled and reachable by an attacker, directly or through a network path that exposes its SMB service. A workstation mounting an SMB share is using the kernel’s SMB client code, generally under

cifs.ko

, rather than operating ksmbd as a server. Samba deployments using

smbd

are separate code and are not addressed by this patch.


Compound SMB2 requests made the bounds check essential​

SMB2 compound requests are legitimate protocol behavior. A client can combine related operations into one message to reduce network round trips, with each component carrying an offset to the next one. Servers must validate both the outer packet and every inner request element; validating the first SMB2 header is insufficient if an attacker can claim another command begins where no complete command actually exists.

StructureSize2

is one of the first command-specific fields ksmbd reads after the SMB2 header. It tells the server the expected structure size for the command and is part of ksmbd’s request sanity checking. The bug was not that ksmbd failed to compare

StructureSize2

against an expected value. The failure came earlier: it performed the comparison before establishing that the next compound command actually had a

StructureSize2

field within its advertised length.

The upstream change is small, but its placement is the point. ksmbd now checks that the remaining compound-request segment is at least the SMB2 header plus the size of

StructureSize2

before accessing that field. If it is not, the server rejects the malformed input.

This is a recurring defensive requirement in SMB implementations. Fields that direct parsing—lengths, offsets, counts, and chained-command pointers—come from the network and cannot be trusted merely because a packet carried a valid SMB signature or a syntactically plausible first command. The current fix closes one specific early-read condition in ksmbd’s compound request validation path.

The upstream fix landed in Linux 7.2 release-candidate code​

The patch was merged into Torvalds’ mainline tree through the ksmbd server-fixes pull request, which described the set as addressing malformed SMB request handling and connection or session lifetime problems. The commit was included after Linux 7.2-rc3 and is present in the Linux 7.2 release-candidate development line.

That timing creates a deployment gap. Mainline inclusion means the source-tree defect is fixed for distributions, appliance vendors, and administrators building current kernels. It does not mean that every enterprise distribution, NAS appliance, router firmware image, cloud appliance, or embedded Linux vendor has already shipped the correction. Those products often use long-term-support kernel branches and selectively backport security fixes.

The public material reviewed for this CVE does not provide a completed list of fixed stable-kernel versions, distribution advisories, vendor package builds, CVSS score, or exploit status. That missing version mapping is the operational problem with the advisory as published: an administrator cannot reliably clear the finding merely by seeing that an upstream mainline patch exists.

For environments that use vendor kernels, the right verification point is the vendor’s changelog or security tracker, not the visible kernel version alone. A distribution could be on an older numerical branch while carrying the patch, or it could report a newer-looking custom kernel string without the relevant backport. The durable identifier is the upstream ksmbd change titled “validate compound request size before reading StructureSize2.”


What administrators should check now​

The immediate audience is smaller than the CVE’s placement on Microsoft’s portal may imply, but it includes systems that are often difficult to inventory: NAS appliances, home-lab file servers, branch-office Linux appliances, edge devices, and bespoke storage deployments. ksmbd may have been enabled deliberately for a lightweight SMB server, while its TCP exposure later changed through firewall, VPN, container, or cloud-network configuration.

Administrators should verify the following:

  • Confirm whether the ksmbd kernel module is loaded and whether the host is providing SMB shares through ksmbd rather than Samba.
  • Identify whether TCP port 445 is reachable from untrusted networks, guest VLANs, VPN users, or other segments where a hostile client could connect.
  • Check the kernel supplier’s advisory and package changelog for the upstream fix, rather than assuming that the Linux 7.2 development-tree merge has reached a supported release.
  • Where a corrected kernel is unavailable, restrict SMB access to trusted networks and disable ksmbd if the service is not required.
  • Treat Samba and ksmbd as separate products during incident and patch triage; updating Samba does not change the code in fs/ksmbd.

A server’s SMB authentication policy does not remove the parsing exposure by itself. The vulnerable operation is request validation, which occurs as ksmbd processes inbound SMB2 traffic. Network reachability and service enablement are therefore the first facts to establish.

Microsoft’s portal listing should not drive Windows patching​

The most misleading feature of CVE-2026-64578 is its publication venue. Microsoft employees contribute to the Linux kernel, Microsoft’s security organization operates a CVE program, and Microsoft’s Security Update Guide can host records outside the narrow set of flaws remediated by Windows Update. None of that makes this a Windows patch event.

There is no Windows KB number in the published record, no affected Windows build range, and no corresponding indication that Windows Server’s SMB server is implicated. The generic Microsoft Knowledge Base disclaimer accompanying the page likewise says nothing about product scope or a Windows remediation.

For Windows administrators, the useful consequence is negative but concrete: do not schedule a Windows cumulative-update response solely for CVE-2026-64578. For mixed environments, focus instead on Linux machines and appliances that actively run the ksmbd server and obtain the corrected kernel from the supplier responsible for that device.


References​

  1. Primary source: MSRC
    Published: August 9, 2026 at 8:42 AM UTC
  2. Related coverage: msrc.microsoft.com
  3. Related coverage: kernel.googlesource.com
  4. Related coverage: kernel.googlesource.com
  5. Related coverage: nist.gov
  6. Related coverage: nvd.nist.gov
  7. Related coverage: cve.org
  8. Related coverage: sambaxp.org
  9. Related coverage: cve.org
  10. Related coverage: nvd.nist.gov
  11. Related coverage: docs.kernel.org