DEBIAN-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/smbcommon.c.  (1) fp->node list-head reuse.  Durable-preserved handles can remain linked on fci->mfplist 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 scavengerlist after removing them from the global durable idr. Because fp->node is the same listhead used by mfplist, 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 atomicread(&fp->refcount) > 1 and fp->conn under globalft.lock, removes fp from globalft, then drops globalft.lock before unlinking fp from mfplist and freeing it. During that gap fp is still linked on mfplist with fstate == FPINITED.  ksmbdlookupfdinode() under mlock read calls ksmbdfpget() (atomicincnotzero 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() (smbcheckpermdleases-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 atomicsubandtest(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 mintimeout before the next wait.     Clear fp->persistentid inside ksmbdremovedurablefd() right     after idrremove(), so a delayed final close from a holder that     snatched fp does not re-issue idrremove() on a persistent id     that idralloccyclic() in ksmbdopendurablefd() may have     already handed out to a brand-new durable handle.     Bypass the per-conn openfilescount decrement in     _putfdfinal() when fp is detached from any session table     (fp->conn cleared by sessionfdcheck() at durable preserve --     paired with the volatileid 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 persistentid 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 listhead reuse path.    KASAN-enabled direct SMB2 durable-handle coverage that exercised     ksmbddurablescavenger() and non-NULL ksmbdlookupfdinode()     returns while durable handles expired under concurrent rename     lookups, with no KASAN, UAF, list-corruption, ODEBUG, or WARNING     reports. ---truncated---