CVE-2026-64437

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL<br /> <br /> Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on<br /> double SMB2_CANCEL") made smb2_cancel() skip a work whose state is<br /> KSMBD_WORK_CANCELLED, so its cancel_fn cannot be fired a second time. But<br /> KSMBD_WORK has three states (ACTIVE, CANCELLED, CLOSED), and the same<br /> freeing producer path is reached for CLOSED too:<br /> <br /> SMB2_CLOSE on the locking handle -&gt; set_close_state_blocked_works() sets<br /> the deferred work&amp;#39;s state to KSMBD_WORK_CLOSED and wakes the smb2_lock()<br /> worker. The worker takes the non-ACTIVE early-exit, locks_free_lock()s<br /> the file_lock and, because the state is not KSMBD_WORK_CANCELLED, takes<br /> the STATUS_RANGE_NOT_LOCKED branch with "goto out2" -- which, like the<br /> cancelled branch, skips release_async_work(). The work stays on<br /> conn-&gt;async_requests with a live cancel_fn = smb2_remove_blocked_lock<br /> pointing at the freed file_lock.<br /> <br /> A subsequent SMB2_CANCEL for the same AsyncId then passes the<br /> KSMBD_WORK_CANCELLED-only guard (its state is KSMBD_WORK_CLOSED), so<br /> smb2_cancel() fires cancel_fn again over the freed file_lock -- the same<br /> use-after-free fixed, via SMB2_CLOSE instead of a first SMB2_CANCEL:<br /> <br /> BUG: KASAN: slab-use-after-free in __locks_delete_block<br /> __locks_delete_block<br /> locks_delete_block<br /> ksmbd_vfs_posix_lock_unblock<br /> smb2_remove_blocked_lock<br /> smb2_cancel