CVE-2026-64387 is a double-free in the Linux kernel's SMB client driver, specifically in the SMB2_query_directory_init() path when directory query replay logic triggers after a replayable error. The vulnerability scores 9.8 due to kernel heap corruption, but the deeper issue is architectural: replay logic was layered onto an existing state machine without reconciling the state transitions it creates with the cleanup logic's assumptions.
When the replay mechanism handles a replayable error, it frees the response buffer as part of that error path—but the bookkeeping metadata marking that buffer as 'owned' isn't cleared. When the standard cleanup routine later runs, it sees what it believes is an unfreed buffer and frees it again. The fix (resetting response bookkeeping before each attempt) confirms this: the system now explicitly manages state that should have been cleared between replay attempts, but wasn't designed to be.
What matters for defenders: audit every code path where the SMB client maintains its own sequence-number-like bookkeeping that could become stale between a failed attempt and cleanup. The replay mechanism in directory queries is likely not isolated—examine file handle management, lease state handling, and any path where the driver layers its own application-level replay semantics on top of SMB's protocol-level anti-replay mechanisms. The concerning possibility is that different replay triggers could produce different failure phenotypes: this one caused heap corruption, but a similar silent contract violation in file handle management might produce credential leakage, or in lease state handling might corrupt in-flight data rather than crash the system.
The one-line fix addresses this specific double-free but doesn't audit whether other replay paths carry the same hidden assumption. The kernel's SMB client has received less audit attention than TLS implementations, and replay logic often becomes 'entropy code'—functioning without maintenance until failure. Review replay paths by consequence class (memory corruption vs. data leakage vs. state corruption) rather than just counting them.