From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11DB313A258 for ; Sun, 19 Jul 2026 15:45:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784475946; cv=none; b=SPr8xVwnRf/lKVePDNJE04MzuU7YsVOs8wH0NaYPoTZS6XBVMij700D2Jm8YSrouDOi7pM90wJr4ulw69pElJ2Eqy8KNlGza8EMGtENCoCyjIpRUWpRZxQgruRx61Xig1KPZ70TcAdhgMW6Qx2lGcpuZDjKdyjm+CgjkVnfXJZ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784475946; c=relaxed/simple; bh=dwXp1Y9bjakOwsb6C31ACde4kohU5Uurq9VsqTbycgM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=bHlSm76ztCmRmqTBMkofisKtTR9JmtSZ+7ODWyvyYEiBUB4rLkp0QcNQ/IYg6WXn1YKvraUuD+obICGZTaL8oIhUBKag4/BwTCNjW4DRnMtMRm1PgUO56DHWD5dnwji9ofyiq/zYDayHb46r1zUL2JQB6lUubKYtlafLW7T+7Fs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=adX/QI4z; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="adX/QI4z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 753DE1F000E9; Sun, 19 Jul 2026 15:45:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1784475945; bh=DuwV1Lg0vA6HITlJXIjscHx8PkkYedKLKOnYmcPX3JM=; h=From:To:Cc:Subject:Date:Reply-To; b=adX/QI4zMpUk0N4kfr/cZ7j0jttilBYECbFtGpVCPlZ1+tph7mGpOVOGGNSLFH3i1 Mkes5ChihTAU6YYlIdx0mtPjH8TdeutUR3rIzzDE0TsfWd+HRmL88gcRUEVvEJ2U+F a37vDSM5pUyrmp7T1qsAtADyyWLpAVGhB2iYN+8k= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-64142: ksmbd: close durable scavenger races against m_fp_list lookups Date: Sun, 19 Jul 2026 17:40:04 +0200 Message-ID: <2026071929-CVE-2026-64142-4f9d@gregkh> X-Mailer: git-send-email 2.55.0 Reply-To: , Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=6285; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=0AUiylg1Ck5VptT88nFfoP0OTOd0QhwJyLsS6yGoAtg=; b=owGbwMvMwCRo6H6F97bub03G02pJDFkx70tXZXVocc/+yZYT9uDt8R8nzlV6tPVtt+LPrvt7i HmD846VHbEsDIJMDLJiiixftvEc3V9xSNHL0PY0zBxWJpAhDFycAjARrWiGBb2RJ872HtDx2p8s 9yNn5a9wHYOYTIYFW6MLmw10WvfVbJqz86+mr8e2p08eAAA= X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman Description =========== 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. * checkpatch --strict * make -j$(nproc) M=fs/smb/server The Linux kernel CVE team has assigned CVE-2026-64142 to this issue. Affected and fixed versions =========================== Issue introduced in 6.11 with commit d484d621d40f4a8b8959008802d79bef3609641b and fixed in 6.12.92 with commit 95f072ef934ca00711d510676b8792cbf59a5aae Issue introduced in 6.11 with commit d484d621d40f4a8b8959008802d79bef3609641b and fixed in 6.18.34 with commit 5da69a65b282d2276de22e5194ba0f88c836170c Issue introduced in 6.11 with commit d484d621d40f4a8b8959008802d79bef3609641b and fixed in 7.0.11 with commit 1f8f3246d55f89350a1a67bdf3744b7241048e4e Issue introduced in 6.11 with commit d484d621d40f4a8b8959008802d79bef3609641b and fixed in 7.1 with commit bf736184d063da1a552ffeff0481813599a182cc 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-64142 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/vfs_cache.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/3a436932eb397e909d0607d76a8325abd9d85a35 https://git.kernel.org/stable/c/95f072ef934ca00711d510676b8792cbf59a5aae https://git.kernel.org/stable/c/5da69a65b282d2276de22e5194ba0f88c836170c https://git.kernel.org/stable/c/1f8f3246d55f89350a1a67bdf3744b7241048e4e https://git.kernel.org/stable/c/bf736184d063da1a552ffeff0481813599a182cc