From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 5DEE92DFF3F for ; Tue, 13 Jan 2026 15:31:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768318264; cv=none; b=UAQMi4hFE8kI2hfOSxlzHFAYXe+s4TLwFZBIANQRAmIK76wVhWQXKcMnNGY7UiFzu94/pMY6bSgVjb+G4gA1yCMjikxuA4gtdwP5IZ4/ni/c1c1swjvDGT3KV8Xmt+2RYWhU1aWMT9wKqi+2888tWNz1dWiBPjstW4v4M8ZtldE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768318264; c=relaxed/simple; bh=/spJX0K2pgKanqKY4sl0LyOb8c9BGvEPnMwl14Ni61U=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=PUl5fy+fbKqzmflox8WKHn9d/RmDvWud+60qKUDzRWaZ4VJJKpXcyM5RJFyllRnZSBCcfj/a4WRt13df5jGj2Khb3a5neuLPgQD6yVV6loMfyTeuub4w6luXH075QzAeXqsmvGbrEv/L4SGgDdBthHZ2uMdKo8FZSYKOP8pEivM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=hoQlSvgs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="hoQlSvgs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59422C116C6; Tue, 13 Jan 2026 15:31:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1768318263; bh=/spJX0K2pgKanqKY4sl0LyOb8c9BGvEPnMwl14Ni61U=; h=From:To:Cc:Subject:Date:Reply-To:From; b=hoQlSvgsISpjtyNjOI5eBqGdDBf5lS7ywwTuQXCmQcQE72EJwO/S2u7te+O0ULbfO Au10NY63gIERSMqWCTCvDI4IROPj08G3FnyvkVsGY+JSCa7JrRMVN1WU7zLlejz94l FjwdvWHmuBYnfGdWtedRIwjugcpwY2JQ+XaEyG2k= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2025-68809: ksmbd: vfs: fix race on m_flags in vfs_cache Date: Tue, 13 Jan 2026 16:29:35 +0100 Message-ID: <2026011311-CVE-2025-68809-e875@gregkh> X-Mailer: git-send-email 2.52.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=3436; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=NtiWwiiWwJDoCzNAUDLZ9C7QfQi3xIEOel2Vaz3UmoE=; b=owGbwMvMwCRo6H6F97bub03G02pJDJlpKcc/BDS3BLLcbCtssNaYckz1xJ2Xywt/Z5i+s+7zV 7VcNOtmRywLgyATg6yYIsuXbTxH91ccUvQytD0NM4eVCWQIAxenAExk5X6G+eVbbm/6e9L3JpMw l4SEX6x3l/3SZwwLlna+srxw7N50r3ablS1Mv18HPpjzDgA= 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: vfs: fix race on m_flags in vfs_cache ksmbd maintains delete-on-close and pending-delete state in ksmbd_inode->m_flags. In vfs_cache.c this field is accessed under inconsistent locking: some paths read and modify m_flags under ci->m_lock while others do so without taking the lock at all. Examples: - ksmbd_query_inode_status() and __ksmbd_inode_close() use ci->m_lock when checking or updating m_flags. - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close() used to read and modify m_flags without ci->m_lock. This creates a potential data race on m_flags when multiple threads open, close and delete the same file concurrently. In the worst case delete-on-close and pending-delete bits can be lost or observed in an inconsistent state, leading to confusing delete semantics (files that stay on disk after delete-on-close, or files that disappear while still in use). Fix it by: - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock after dropping inode_hash_lock. - Adding ci->m_lock protection to all helpers that read or modify m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()). - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(), and moving the actual unlink/xattr removal outside the lock. This unifies the locking around m_flags and removes the data race while preserving the existing delete-on-close behaviour. The Linux kernel CVE team has assigned CVE-2025-68809 to this issue. Affected and fixed versions =========================== Fixed in 6.6.120 with commit 5adad9727a815c26013b0d41cfee92ffa7d4037c Fixed in 6.12.64 with commit ccc78781041589ea383e61d5d7a1e9a31b210b93 Fixed in 6.18.3 with commit ee63729760f5b61a66f345c54dc4c7514e62383d Fixed in 6.19-rc1 with commit 991f8a79db99b14c48d20d2052c82d65b9186cad 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-2025-68809 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/5adad9727a815c26013b0d41cfee92ffa7d4037c https://git.kernel.org/stable/c/ccc78781041589ea383e61d5d7a1e9a31b210b93 https://git.kernel.org/stable/c/ee63729760f5b61a66f345c54dc4c7514e62383d https://git.kernel.org/stable/c/991f8a79db99b14c48d20d2052c82d65b9186cad