[{"id":3683795,"web_url":"http://patchwork.ozlabs.org/comment/3683795/","msgid":"<CAKYAXd8KY1=yK9BCR1TdRBkH5DDj6Fn5-bgV-UBxb+M0mqbPWw@mail.gmail.com>","list_archive_url":null,"date":"2026-04-29T03:21:40","subject":"Re: [PATCH v2 0/3] ksmbd: fix connection and durable handle teardown\n races","submitter":{"id":79386,"url":"http://patchwork.ozlabs.org/api/people/79386/","name":"Namjae Jeon","email":"linkinjeon@kernel.org"},"content":"On Tue, Apr 28, 2026 at 11:09 PM DaeMyung Kang <charsyam@gmail.com> wrote:\n>\n> This series fixes lifetime bugs around ksmbd connection shutdown,\n> session file-table teardown, and durable handle scavenging.\n>\n> Patch 1 centralizes the final struct ksmbd_conn release so every last\n> putter runs ida_destroy() and transport cleanup.  The release is queued\n> to a dedicated workqueue because transport teardown can sleep, while\n> one known last-putter is an RCU callback.\n>\n> Patch 2 hardens __close_file_table_ids() by taking a transient\n> ksmbd_file reference, unpublishing from the session idr under ft->lock,\n> and doing sleepable preserve/close work outside ft->lock.  It also\n> makes the FP_NEW window visible to the opener through\n> ksmbd_update_fstate().\n>\n> Patch 2 is scoped to file-table teardown and the FP_NEW publication\n> window.  It does not try to fix durable reconnect rollback on later\n> smb2_open() error paths (and the related post-FP_INITED reference\n> window in fresh smb2_open).  Both already exist before this series\n> and need either an explicit unpublish-on-error step or an extra\n> session-owned reference.  That is left as follow-up work.  The\n> FP_NEW -> FP_INITED failure reuses smb2_open()'s existing -ENOENT to\n> STATUS_OBJECT_NAME_INVALID mapping to avoid changing wire behavior in\n> this lifetime fix.\n>\n> Patch 3 closes two related races in the durable scavenger against any\n> walker that iterates f_ci->m_fp_list (ksmbd_lookup_fd_inode() and the\n> share-mode checks).  The scavenger no longer reuses fp->node as a\n> scavenger-private collect-list node, takes an explicit transient\n> reference under global_ft.lock, and drops both the durable lifetime\n> and transient refs with atomic_sub_and_test(2, ...) after the\n> m_fp_list unlink so an in-flight m_fp_list walker that snatched fp\n> owns the final close cleanly.  fp->persistent_id is cleared inside\n> __ksmbd_remove_durable_fd() so a delayed final close cannot re-issue\n> idr_remove() on a slot that idr_alloc_cyclic() may have already\n> re-handed to a new durable handle.  __put_fd_final() bypasses the\n> per-conn open_files_count decrement when fp is detached from any\n> session table (fp->conn cleared by session_fd_check() at durable\n> preserve, paired with the volatile_id clear at unpublish), since the\n> walker that owns the final close in that case runs from an unrelated\n> work->conn whose counter never tracked this durable fp.\n>\n> The series is intentionally scoped to lifetime/race fixes and the\n> walker-final-putter regression that the durable scavenger handoff in\n> patch 3 newly exposes.  Pre-existing reconnect rollback and per-conn\n> open_files_count accounting gaps are left as follow-up work so this\n> series does not have to claim a full durable-reconnect or accounting\n> cleanup.\n>\n> Validation:\n>   * abrupt-disconnect kmemleak/kprobe A/B for connection release\n>   * same-session two-tcon DEBUG_LIST/DEBUG_OBJECTS_WORK stress\n>   * forced durable-preserve sleep-path harness for session teardown\n>   * KASAN-enabled direct SMB2 coverage for session/tree teardown and\n>     durable-preserve paths\n>   * KASAN-enabled direct SMB2 coverage for durable scavenger expiry\n>     racing with m_fp_list lookups\n>   * checkpatch --strict for all patches\n>   * make -j$(nproc) M=fs/smb/server\n>\n> v1 -> v2:\n>   * Split the original change into bisectable patches: connection final\n>     release, session file-table teardown, and durable scavenger races.\n>   * Keep sleepable session preserve/close work out of ft->lock and make\n>     the FP_NEW publication race visible through a cleared volatile id.\n>   * Document that durable reconnect rollback on later smb2_open()\n>     error paths is a pre-existing follow-up item, and keep the\n>     existing -ENOENT to STATUS_OBJECT_NAME_INVALID wire mapping for\n>     this lifetime fix.\n>   * Avoid reusing fp->node as a temporary durable scavenger list node\n>     and take a transient reference in the durable scavenger so\n>     concurrent ksmbd_lookup_fd_inode() walkers cannot UAF on freed fp.\n>     These two fixes are folded into a single patch because the\n>     list-head-reuse fix alone leaves a deterministic UAF window for\n>     m_fp_list walkers; bisecting onto an intermediate state would land\n>     on a use-after-free that pre-patch chaos merely made less\n>     reproducible.\n>   * Clear fp->persistent_id in __ksmbd_remove_durable_fd() so a holder\n>     that owns the final close after a scavenger removal does not\n>     re-issue idr_remove() on a persistent id that may have already been\n>     handed out to a new durable handle.\n>   * Bypass the per-conn open_files_count decrement in __put_fd_final()\n>     when fp is detached from any session table, so an m_fp_list walker\n>     that owns the final close of a scavenged durable fp does not\n>     underflow an unrelated conn's stats counter.\n>   * Document the ksmbd_conn_wq lifetime invariant in ksmbd_conn_put()\n>     instead of guarding with WARN_ON_ONCE, so a violation surfaces as\n>     a NULL deref rather than a silent leak of the final release.\n>\n> DaeMyung Kang (3):\n>   ksmbd: centralize ksmbd_conn final release to plug transport leak\n>   ksmbd: harden file lifetime during session teardown\n>   ksmbd: close durable scavenger races against m_fp_list lookups\nApplied them to #ksmbd-for-next-next.\nThanks!","headers":{"Return-Path":"\n <linux-cifs+bounces-11265-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-cifs@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=mopcc48y;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-cifs+bounces-11265-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"mopcc48y\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g52fG3wb6z1xvV\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 29 Apr 2026 13:21:58 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 47ABA3008D2E\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 29 Apr 2026 03:21:56 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id D09692C11F1;\n\tWed, 29 Apr 2026 03:21:54 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id AD3EAA59\n\tfor <linux-cifs@vger.kernel.org>; Wed, 29 Apr 2026 03:21:54 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 5815AC2BCC6\n\tfor <linux-cifs@vger.kernel.org>; Wed, 29 Apr 2026 03:21:54 +0000 (UTC)","by mail-ed1-f48.google.com with SMTP id\n 4fb4d7f45d1cf-65c0891f4e9so19954977a12.1\n        for <linux-cifs@vger.kernel.org>;\n Tue, 28 Apr 2026 20:21:54 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777432914; cv=none;\n b=JNhFtI8ETCZkpbAzfyH+0UuU4+heN7BXj026Fkyw4ySG7Eu6waNbJCksIB5r5ejXNgQuL9d5bHUHThXxQkil+vkC38sCDZI/QzlKn8XcEtGtmB7P2PNZ/2Sv1DWITJr+AzKgX7/+FkiTuvKoeTWDirJGmmKwcF6q27JO4bt/ems=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777432914; c=relaxed/simple;\n\tbh=Z8BA/oqgcjh5iOc1A3di8CSkn+8P52xYrUtv6vnlbNI=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=TtEQzn4hOsZO7V469+Mwo8BF3zNJz86CsMaGSrdDd34F2+uxPGxCkB+7rj/TENhun4HBDZug20fH2doKuUQR7RpbsyJ94LcdiAdD5STGEZC6nQTEP26gpbBuMZFtKZjlHVgou8BxqTs5wfJRV3HI7Xf2QjJxrs14JFeOZ/ZoAqo=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=mopcc48y; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777432914;\n\tbh=Z8BA/oqgcjh5iOc1A3di8CSkn+8P52xYrUtv6vnlbNI=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=mopcc48yevR2PFrWqI3Hm9MtbYjZD2OztPDspin/FgPWilecR2iFrh97TE9f7Jpm7\n\t Vb0C74PwJfJ0n7jEvVIuxRQArcH1/4j8HjJG9fa4E9/N/cG757VFvq2ArWdT9OBUEs\n\t FK+o/tPBS5wOQklzdpJ+n+n4uZxjAUnPWkIJsu3zEGQb634ZYJvg8tNsQkzr4G5Woe\n\t 8mMaCf+7lbE9wb0pvGIWgZMwkZPN1Luw+hu9Zd0usNDDuVKedvc8CEUr3RMNJZO9P6\n\t ySJc9SDw8q0Lu+cazZsQL7TrRCeoKVvRV0Pf9eqekdEEJl/Ul/ebgtWCSK2ZFp0A9+\n\t 4tfvisYQlj3Ag==","X-Forwarded-Encrypted":"i=1;\n AFNElJ8Ud4oCSOTciz1koNtIBAriuIK8XxPiYYAlj09+y6PZe0AYzPWfEv3vUVDJrB+JxDphXxjE2+kgP1Vy@vger.kernel.org","X-Gm-Message-State":"AOJu0YwMtoMRG6+mJBsrmRndnh7z60wmVsdJhW0mcalwm4UrxviiqPFk\n\tLjfg2pQw3IaHFdOclMRK5E8FcVgNfePEgp3Pt9ZBirs1IOrUwZ8+PO6x/raoWr8OGfH1AFE+l4r\n\t1aBGydxc0znwpQYuIG8Nxtnl9rL/jvz4=","X-Received":"by 2002:a05:6402:324c:b0:66e:378d:2e56 with SMTP id\n 4fb4d7f45d1cf-679bb03e227mr2535239a12.6.1777432912945; Tue, 28 Apr 2026\n 20:21:52 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-cifs@vger.kernel.org","List-Id":"<linux-cifs.vger.kernel.org>","List-Subscribe":"<mailto:linux-cifs+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-cifs+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","References":"<20260428140856.941847-1-charsyam@gmail.com>","In-Reply-To":"<20260428140856.941847-1-charsyam@gmail.com>","From":"Namjae Jeon <linkinjeon@kernel.org>","Date":"Wed, 29 Apr 2026 12:21:40 +0900","X-Gmail-Original-Message-ID":"\n <CAKYAXd8KY1=yK9BCR1TdRBkH5DDj6Fn5-bgV-UBxb+M0mqbPWw@mail.gmail.com>","X-Gm-Features":"AVHnY4JZ8wLJe-D-Kp6bltQlLocEo77QRUZm9qJD3e4aKrGRJY0OtoqCN_Vs7_Q","Message-ID":"\n <CAKYAXd8KY1=yK9BCR1TdRBkH5DDj6Fn5-bgV-UBxb+M0mqbPWw@mail.gmail.com>","Subject":"Re: [PATCH v2 0/3] ksmbd: fix connection and durable handle teardown\n races","To":"DaeMyung Kang <charsyam@gmail.com>","Cc":"Steve French <smfrench@gmail.com>,\n Sergey Senozhatsky <senozhatsky@chromium.org>,\n\tTom Talpey <tom@talpey.com>, Hyunchul Lee <hyc.lee@gmail.com>,\n\tRonnie Sahlberg <lsahlber@redhat.com>, linux-cifs@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}}]