CVE-2026-64597 is a double-free in the SMB2 client kernel code, specifically in the close() operation's retry path. When the SMB protocol requires a request replay due to network timeout or transient failure, the client correctly retries the operation—but the bookkeeping state tracking the response buffer was not reset between retry iterations. The response gets freed in the error-handling path of the first failed attempt, then gets freed again when cleanup runs after the next send fails, producing the use-after-free.
The vulnerable pattern is a stateful retry loop where shared buffers persist across iterations. The fix resets response bookkeeping before each retry attempt, ensuring the cleanup routine knows whether the buffer has already been processed. This is a micro-fix, but it addresses a recurring vulnerability class in kernel networking code: retry loops that hold shared state across failure modes.
For defenders: audit any SMB client retry logic in your kernel for similar patterns. The specific variable to check is the response buffer type indicator—whether it's properly cleared or reset when an error path frees the buffer before a retry. More broadly, treat any code path where network retry meets kernel memory allocation as higher-risk: the blast radius crosses from network input into kernel heap, and the SMB client sits in that critical intersection. Look for other retry loops in your SMB implementation (open, write, query-directory operations all use similar patterns) and verify their state reset is explicit, not assumed.
For prioritization: this is a kernel heap corruption vector from untrusted network input. The impact is crash or potentially privilege escalation depending on heap grooming. Patch immediately on affected kernels—Ubuntu 22.04+, RHEL 9+, and downstream kernels shipping the 5.15+ SMB client are exposed.