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 6C479392838; Wed, 7 Jan 2026 15:53:36 +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=1767801216; cv=none; b=lenOu5PZRSrg5EGuBUamw5FcFsKGV9oiJZFMAWyc4zGcLajN57KeKpLslNg8XqhbnJLYhDnha6fS6cpjszU4gHn0T9kJ7AhXLjz5jZwpe1f9BdNFWjr+804Rbzkz2v3wlNa2ZFWUew/aDA87RSheQpW08xeK4MioX9eD/JwZ1Gk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767801216; c=relaxed/simple; bh=cbuhn2GE9sik3u9T+uUC/6rl0GNp/R2VX6KZN551EKg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nXkMXTa99OB7NM6qRRpWueaMnxH6XYv0MLFm9lEtIsP2dh1K1UNwBk1F8XFquG+BF3t75SXhKxk4WIWAKVk02Vo38n4QcXavzqY/m552Koq8f4EL6HczMq6cbSyHhF8fLkhsr5NzDyekoxicHXv4YIboDFTIxO15SPJvbqW/+SM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V7eYQaId; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V7eYQaId" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5151FC4CEF7; Wed, 7 Jan 2026 15:53:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767801214; bh=cbuhn2GE9sik3u9T+uUC/6rl0GNp/R2VX6KZN551EKg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V7eYQaIdqzgE06dl/u6QjYrfqjOP8WMXPt2cpQUUE+A1tqhxMECBlYdLFbFeXemDr bmAE6NOxu5ESQZm76aAWXsAhgzI60uKrXi++XMYQ8LhhqjoVBrPCJHge3/chE0e0Vr IRj5cZI1fTDSK6hUa7tu8OnlhJTcUtGWs65Wt8YzPF1ciXrNGXysAPjardzbs9m1EK mKFy0kUIj3cWwsIfapsHLzotrgovr2Z1i1aGk1+cxPFDA3mZZ4bkzkTh1yUSNBgQ20 z2ALsCk2QE1OHBEF7Bd+8vVuAtIGdBb8SAms7YuVvAMaP5qKScF8BOeGF4wjbO+K2R xs/ndfZ+iLEvA== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: ZhangGuoDong , Namjae Jeon , ChenXiaoSong , Steve French , Sasha Levin , smfrench@gmail.com, linux-cifs@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-6.6] smb/server: fix refcount leak in smb2_open() Date: Wed, 7 Jan 2026 10:53:05 -0500 Message-ID: <20260107155329.4063936-3-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260107155329.4063936-1-sashal@kernel.org> References: <20260107155329.4063936-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: ZhangGuoDong [ Upstream commit f416c556997aa56ec4384c6b6efd6a0e6ac70aa7 ] When ksmbd_vfs_getattr() fails, the reference count of ksmbd_file must be released. Suggested-by: Namjae Jeon Signed-off-by: ZhangGuoDong Signed-off-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: ## Commit Analysis: smb/server: fix refcount leak in smb2_open() ### 1. COMMIT MESSAGE ANALYSIS The commit message is clear and concise: - **Subject:** Explicitly identifies this as a "fix" for a "refcount leak" - **Body:** Explains the bug - when `ksmbd_vfs_getattr()` fails, the reference count of `ksmbd_file` is not being released - **Tags:** Has Suggested-by from Namjae Jeon (ksmbd maintainer), Acked- by from same maintainer, and signed off by Steve French (SMB/CIFS maintainer) The maintainer involvement indicates this is a legitimate bug fix. ### 2. CODE CHANGE ANALYSIS Let me examine the exact change: ```c // BEFORE: rc = ksmbd_vfs_getattr(&fp->filp->f_path, &stat); if (rc) goto err_out2; ksmbd_put_durable_fd(fp); goto reconnected_fp; // AFTER: rc = ksmbd_vfs_getattr(&fp->filp->f_path, &stat); ksmbd_put_durable_fd(fp); if (rc) goto err_out2; goto reconnected_fp; ``` **The Bug:** In the original code, when `ksmbd_vfs_getattr()` fails (returns non- zero), the code jumps directly to `err_out2` **without** calling `ksmbd_put_durable_fd(fp)`. This means the reference count acquired earlier (via `ksmbd_reopen_durable_fd`) is never released - a classic refcount leak. **The Fix:** Move `ksmbd_put_durable_fd(fp)` to before the error check so the reference is released in both success and error paths. This is the correct pattern for resource cleanup. ### 3. CLASSIFICATION - **Type:** Bug fix (resource leak) - **Severity:** Medium - refcount leaks can lead to memory exhaustion over time - **Component:** ksmbd (kernel SMB server) - fs/smb/server/ ### 4. SCOPE AND RISK ASSESSMENT - **Lines changed:** 2 (one line moved) - **Files changed:** 1 (fs/smb/server/smb2pdu.c) - **Complexity:** Very low - straightforward line repositioning - **Risk:** Very low - the fix is obviously correct and doesn't change any logic, just ensures cleanup happens unconditionally ### 5. USER IMPACT - **Affected users:** Systems running ksmbd (kernel SMB server) - **Trigger condition:** When a durable file handle reconnection attempt has `ksmbd_vfs_getattr()` fail - **Consequence of bug:** Reference count leak leading to potential resource exhaustion over time - **Severity:** Important for production SMB servers that may run for extended periods ### 6. STABILITY INDICATORS - ✅ Acked-by from subsystem maintainer (Namjae Jeon) - ✅ Suggested-by from the same maintainer - ✅ Signed-off by Steve French (CIFS/SMB maintainer) - ✅ Small, surgical fix with clear scope ### 7. DEPENDENCY CHECK This is a standalone fix. The code path exists in all kernels with ksmbd support (5.15+). No other commits are required for this fix to work. ### STABLE KERNEL CRITERIA ASSESSMENT | Criterion | Status | |-----------|--------| | Obviously correct | ✅ Yes - reference must be released in both paths | | Fixes real bug | ✅ Yes - refcount leak is a real resource management bug | | Important issue | ✅ Yes - can cause resource exhaustion | | Small and contained | ✅ Yes - 2 lines, single file | | No new features | ✅ Yes - pure bugfix | | Applies cleanly | ✅ Should apply cleanly | ### CONCLUSION This is an ideal stable backport candidate: - **Clear bug:** Reference count leak when error path is taken - **Obvious fix:** Move cleanup before error check - **Minimal change:** Single line repositioned - **Low risk:** No logic changes, just proper resource management - **Maintainer endorsed:** Acked by ksmbd maintainer The fix addresses a resource leak that could affect production SMB servers over time. The change is trivial (one line moved), obviously correct, and has zero risk of introducing regressions. **YES** fs/smb/server/smb2pdu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index e052dcb9a14c..3795fb90e161 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -3019,10 +3019,10 @@ int smb2_open(struct ksmbd_work *work) file_info = FILE_OPENED; rc = ksmbd_vfs_getattr(&fp->filp->f_path, &stat); + ksmbd_put_durable_fd(fp); if (rc) goto err_out2; - ksmbd_put_durable_fd(fp); goto reconnected_fp; } } else if (req_op_level == SMB2_OPLOCK_LEVEL_LEASE) -- 2.51.0