PT-2026-61459 · Linux · Linux

CVE-2026-64142

·

Published

2026-07-19

·

Updated

2026-07-19

CVSS v3.1

9.8

Critical

VectorAV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: close durable scavenger races against m fp list lookups
ksmbd durable scavenger() has two related races against any walker that iterates f ci->m fp list, including ksmbd lookup fd inode() (used by ksmbd vfs rename) 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 f ci->m fp 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 list head used by m fp list, list add(&fp->node, &scavenger list) overwrites the m fp list links and corrupts both lists. CONFIG DEBUG LIST can report this on the share-mode walk path.
(2) Refcount race against m fp list walkers. The scavenger qualifies an expired durable handle with atomic read(&fp->refcount) > 1 and fp->conn under global ft.lock, removes fp from global ft, then drops global ft.lock before unlinking fp from m fp list and freeing it. During that gap fp is still linked on m fp list with f state == FP INITED. ksmbd lookup fd inode() under m lock read calls ksmbd fp get() (atomic inc not 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 ksmbd fd put() and on any field reads performed by a concurrent share-mode walker that iterates m fp list without taking ksmbd fp get() (smb check perm dleases-like paths).
Fix both:
  • Stop reusing fp->node as a scavenger-private list node. Remove one expired handle from global ft under global ft.lock, take an explicit transient reference, drop the lock, unlink fp->node from m fp list under f ci->m lock, then drop both the durable lifetime and transient references with atomic sub and 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 m fp list lookup owns the final close via its ksmbd fd put() 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->persistent id inside ksmbd remove durable fd() 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 idr alloc cyclic() in ksmbd open durable fd() may have already handed out to a brand-new durable handle.
  • Bypass the per-conn open files count decrement in put fd final() when fp is detached from any session table (fp->conn cleared by session fd check() 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.open files count 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 m fp list 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:
  • CONFIG DEBUG LIST coverage for the list head reuse path.
  • KASAN-enabled direct SMB2 durable-handle coverage that exercised ksmbd durable scavenger() and non-NULL ksmbd lookup fd inode() returns while durable handles expired under concurrent rename lookups, with no KASAN, UAF, list-corruption, ODEBUG, or WARNING reports. ---truncated---

Fix

Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-64142

Affected Products

Linux