CVE-2026-52996

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open<br /> <br /> ksmbd_lookup_fd_cguid() returns a ksmbd_file with its refcount<br /> incremented via ksmbd_fp_get(). parse_durable_handle_context() in<br /> the DURABLE_REQ_V2 case properly releases this reference on every<br /> path inside the ClientGUID-match branch, either by calling<br /> ksmbd_put_durable_fd() or by transferring ownership to dh_info-&gt;fp<br /> for a successful reconnect. However, when an entry exists in the<br /> global file table with the same CreateGuid but a different<br /> ClientGUID, the code simply falls through to the new-open path<br /> without dropping the reference obtained from ksmbd_lookup_fd_cguid().<br /> <br /> Per MS-SMB2 section 3.3.5.9.10 ("Handling the<br /> SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context"), the server<br /> MUST locate an Open whose Open.CreateGuid matches the request&amp;#39;s<br /> CreateGuid AND whose Open.ClientGuid matches the ClientGuid of the<br /> connection that received the request. If no such Open is found, the<br /> server MUST continue with the normal open execution phase. A<br /> CreateGuid hit with a ClientGUID mismatch is therefore the<br /> "Open not found" case: proceeding with a new open is correct, but<br /> the reference obtained purely as a side effect of the lookup must<br /> not be leaked.<br /> <br /> Repeated requests that hit this mismatch pin global_ft entries,<br /> prevent __ksmbd_close_fd() from ever running for the corresponding<br /> files, and defeat the durable scavenger, leading to long-lived<br /> resource leaks.<br /> <br /> Release the reference in the mismatch path and clear dh_info-&gt;fp so<br /> subsequent logic does not mistake a non-matching lookup result for<br /> a reconnect target.