CVE-2026-64437: ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL

From: Greg Kroah-Hartman <[email protected]>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL

Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on
double SMB2_CANCEL") made smb2_cancel() skip a work whose state is
KSMBD_WORK_CANCELLED, so its cancel_fn cannot be fired a second time. But
KSMBD_WORK has three states (ACTIVE, CANCELLED, CLOSED), and the same
freeing producer path is reached for CLOSED too:

  SMB2_CLOSE on the locking handle -> set_close_state_blocked_works() sets
  the deferred work's state to KSMBD_WORK_CLOSED and wakes the smb2_lock()
  worker. The worker takes the non-ACTIVE early-exit, locks_free_lock()s
  the file_lock and, because the state is not KSMBD_WORK_CANCELLED, takes
  the STATUS_RANGE_NOT_LOCKED branch with "goto out2" -- which, like the
  cancelled branch, skips release_async_work(). The work stays on
  conn->async_requests with a live cancel_fn = smb2_remove_blocked_lock
  pointing at the freed file_lock.

A subsequent SMB2_CANCEL for the same AsyncId then passes the
KSMBD_WORK_CANCELLED-only guard (its state is KSMBD_WORK_CLOSED), so
smb2_cancel() fires cancel_fn again over the freed file_lock -- the same
use-after-free fixed, via SMB2_CLOSE instead of a first SMB2_CANCEL:

  BUG: KASAN: slab-use-after-free in __locks_delete_block
    __locks_delete_block
    locks_delete_block
    ksmbd_vfs_posix_lock_unblock
    smb2_remove_blocked_lock
    smb2_cancel                 <- 2nd SMB2_CANCEL fires cancel_fn
    handle_ksmbd_work
  Allocated by ...: locks_alloc_lock <- smb2_lock
  Freed by ...:     locks_free_lock  <- smb2_lock (non-ACTIVE early-exit)
  ... cache file_lock_cache of size 192

Reproduced on mainline 7.1-rc7 (which already contains f580d27e8928) with
KASAN by an authenticated SMB client; the double-SMB2_CANCEL control is
silent on that kernel, so the splat is attributable to the CLOSE trigger.

Only an ACTIVE deferred work may have its cancel_fn fired: both terminal
states (CANCELLED and CLOSED) reach the smb2_lock() early-exit that frees
the file_lock and skips release_async_work(). Guard on KSMBD_WORK_ACTIVE
so any non-active work is skipped.

The Linux kernel CVE team has assigned CVE-2026-64437 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.1.176 with commit b7063c7426ea5a4d15e01b60538718765392f49d and fixed in 6.1.178 with commit a796ba4e61d5e14e07b79a359faac69f8f9b22a3
	Issue introduced in 6.6.143 with commit 0da2e073f9cbf4985a0fd9acb71bc5ff599f8afd and fixed in 6.6.145 with commit b8e274e69ab09222c7a552c7c0c1eef9ce627fc1
	Issue introduced in 6.12.94 with commit 89ae9df09d2c1fb4a4eb495c113a7ce1dca34147 and fixed in 6.12.96 with commit ddb9239828336b36d8a3ef5943fdffb2f55b6508
	Issue introduced in 6.18.36 with commit 14d2eee0193ac3cd1bf3d014373449f0b8d35d6d and fixed in 6.18.39 with commit 94083db751930b1540ddff2b54d4677549c57f81
	Issue introduced in 7.1 with commit f580d27e8928828693df44ba2db0fffdbe11dfea and fixed in 7.1.4 with commit 12c36c99655f325befe50c26842f7deca414c381
	Issue introduced in 7.1 with commit f580d27e8928828693df44ba2db0fffdbe11dfea and fixed in 7.2-rc1 with commit 10f293a07f9e10e988b0ae44e2e99c631f5a68e0
	Issue introduced in 7.0.13 with commit 2b2eda2821cff1d1b5a423b6ee7d8fc6fbc8e694

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-64437
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/smb/server/smb2pdu.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/a796ba4e61d5e14e07b79a359faac69f8f9b22a3
	https://git.kernel.org/stable/c/b8e274e69ab09222c7a552c7c0c1eef9ce627fc1
	https://git.kernel.org/stable/c/ddb9239828336b36d8a3ef5943fdffb2f55b6508
	https://git.kernel.org/stable/c/94083db751930b1540ddff2b54d4677549c57f81
	https://git.kernel.org/stable/c/12c36c99655f325befe50c26842f7deca414c381
	https://git.kernel.org/stable/c/10f293a07f9e10e988b0ae44e2e99c631f5a68e0