CVE-2026-64142

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

ksmbd: close durable scavenger races against mfplist lookups

ksmbddurablescavenger() has two related races against any walker

that iterates fci->mfplist, including ksmbdlookupfdinode()

(used by ksmbdvfsrename) and the share-mode checks in

fs/smb/server/smb_common.c.

(1) fp->node list-head reuse.  Durable-preserved handles can remain

linked on fci->mfp_list after session teardown so share-mode checks

still see them while the handle is reconnectable.  The scavenger

collected expired handles by adding fp->node to a local

scavenger_list after removing them from the global durable idr.

Because fp->node is the same listhead used by mfp_list,

listadd(&fp->node, &scavengerlist) overwrites the mfplist links

and corrupts both lists.  CONFIGDEBUGLIST can report this on the

share-mode walk path.

(2) Refcount race against mfplist walkers.  The scavenger qualifies

an expired durable handle with atomic_read(&fp->refcount) > 1 and

fp->conn under globalft.lock, removes fp from globalft, then drops

globalft.lock before unlinking fp from mfp_list and freeing it.

During that gap fp is still linked on mfplist with f_state ==

FPINITED.  ksmbdlookupfdinode() under m_lock read calls

ksmbdfpget() (atomicincnot_zero on refcount that is still 1) and

takes a live reference; the scavenger then unlinks and frees fp

while the holder owns a reference, leading to UAF on the holder's

subsequent ksmbdfdput() and on any field reads performed by a

concurrent share-mode walker that iterates mfplist without taking

ksmbdfpget() (smbcheckperm_dleases-like paths).

Fix both:

• Stop reusing fp->node as a scavenger-private list node.  Remove

    one expired handle from globalft under globalft.lock, take an

    explicit transient reference, drop the lock, unlink fp->node

    from mfplist under fci->mlock, then drop both the durable

    lifetime and transient references with atomicsuband_test(2,

    &fp->refcount).  If the scavenger is the last putter the close

    runs there; otherwise an in-flight holder that already raced

    through the mfplist lookup owns the final close via its

    ksmbdfdput() path.  The one-at-a-time disposal can rescan the

    durable idr when multiple handles expire in the same pass, but

    durable scavenging is a background expiration path and the final

    full scan recomputes min_timeout before the next wait.

• Clear fp->persistentid inside ksmbdremovedurablefd() right

    after idr_remove(), so a delayed final close from a holder that

    snatched fp does not re-issue idr_remove() on a persistent id

    that idralloccyclic() in ksmbdopendurable_fd() may have

    already handed out to a brand-new durable handle.

• Bypass the per-conn openfilescount decrement in

    _putfd_final() when fp is detached from any session table

    (fp->conn cleared by sessionfdcheck() at durable preserve --

    paired with the volatile_id clear at unpublish, so checking

    fp->conn alone is sufficient).  The walker that owns the final

    close runs from an unrelated work->conn whose

    stats.openfilescount never tracked this durable fp; without

    this guard the holder would underflow that unrelated counter.

The two races are folded into one patch because patch (1) alone

cleans up the corrupted list but leaves a deterministic UAF window

for mfplist walkers that the transient-reference and

persistent_id discipline in (2) close; bisecting onto an

intermediate state would land on a UAF that pre-patch chaos merely

made less reproducible.

Validation:

• CONFIGDEBUGLIST coverage for the list_head reuse path.
• KASAN-enabled direct SMB2 durable-handle coverage that exercised

    ksmbddurablescavenger() and non-NULL ksmbdlookupfd_inode()

    returns while durable handles expired under concurrent rename

    lookups, with no KASAN, UAF, list-corruption, ODEBUG, or WARNING

    reports.

---truncated---