{"id":2224110,"url":"http://patchwork.ozlabs.org/api/patches/2224110/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-cifs-client/patch/20260416204539.3536168-1-charsyam@gmail.com/","project":{"id":12,"url":"http://patchwork.ozlabs.org/api/projects/12/?format=json","name":"Linux CIFS Client","link_name":"linux-cifs-client","list_id":"linux-cifs.vger.kernel.org","list_email":"linux-cifs@vger.kernel.org","web_url":"","scm_url":"","webscm_url":"","list_archive_url":"","list_archive_url_format":"","commit_url_format":""},"msgid":"<20260416204539.3536168-1-charsyam@gmail.com>","list_archive_url":null,"date":"2026-04-16T20:45:39","name":"[v3] smb/client: fix state corruption in smb3_reconfigure multichannel path","commit_ref":null,"pull_url":null,"state":"new","archived":false,"hash":"2b3550907af0c9b64ca6f05707a2398b46f83715","submitter":{"id":93166,"url":"http://patchwork.ozlabs.org/api/people/93166/?format=json","name":"CharSyam","email":"charsyam@gmail.com"},"delegate":null,"mbox":"http://patchwork.ozlabs.org/project/linux-cifs-client/patch/20260416204539.3536168-1-charsyam@gmail.com/mbox/","series":[{"id":500203,"url":"http://patchwork.ozlabs.org/api/series/500203/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-cifs-client/list/?series=500203","date":"2026-04-16T20:45:39","name":"[v3] smb/client: fix state corruption in smb3_reconfigure multichannel path","version":3,"mbox":"http://patchwork.ozlabs.org/series/500203/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/patches/2224110/comments/","check":"pending","checks":"http://patchwork.ozlabs.org/api/patches/2224110/checks/","tags":{},"related":[],"headers":{"Return-Path":"\n ","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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=lReweN1q;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-cifs+bounces-10873-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=\"lReweN1q\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.85.216.51","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=gmail.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxVQl5kXJz1yCv\n\tfor ; Fri, 17 Apr 2026 06:45:51 +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 3B063307921B\n\tfor ; Thu, 16 Apr 2026 20:45:49 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 660A02F8BF0;\n\tThu, 16 Apr 2026 20:45:48 +0000 (UTC)","from mail-pj1-f51.google.com (mail-pj1-f51.google.com\n [209.85.216.51])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id EA69F2DEA9D\n\tfor ; Thu, 16 Apr 2026 20:45:46 +0000 (UTC)","by mail-pj1-f51.google.com with SMTP id\n 98e67ed59e1d1-3597822d6d8so2858a91.3\n for ;\n Thu, 16 Apr 2026 13:45:46 -0700 (PDT)","from ser8.. ([221.156.231.192])\n by smtp.gmail.com with ESMTPSA id\n 98e67ed59e1d1-36132dbce55sm3066326a91.13.2026.04.16.13.45.43\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Thu, 16 Apr 2026 13:45:45 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776372348; cv=none;\n b=ZSs9tSmOuFuVxbxxAgZU7M3Obsj7tb3Hau8vYyxug2qIuY2ggSFt0hTpH2g+5oj6PGBJLgmFanFMrM8S8BkjyH7cC+XOxXOuOHxmxkd/I0U7ebWeCmJiU0qBvQX8AdTPtnY0U2gjl4wm/1roMdgOvgVsYrESNgD3TdrSv5dcuik=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776372348; c=relaxed/simple;\n\tbh=2/YKQepib8qgPE6x6OTTQCVAq0n90vlOEci55qr1yKk=;\n\th=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:\n\t MIME-Version;\n b=Pq7zlihueAjsFqiLAdhWR9cK1UO5MDAou3xjhyYJOSN8+vAb//RG9ueGj4JBiOa7Xd8J66Ru3d1hRNQy+Hftrt3nwWJjFkVwuzOKb/tnV7xJjJffeDuM9yUnG5jXx1eGvMmp3KZ+Rqk0VkCy73wt8tHd2LkkFh26g3/oucswYOU=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com;\n spf=pass smtp.mailfrom=gmail.com;\n dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=lReweN1q; arc=none smtp.client-ip=209.85.216.51","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776372346; x=1776977146;\n darn=vger.kernel.org;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:from:to:cc:subject:date\n :message-id:reply-to;\n bh=GwPWif+GAoWQlSDJUgW/WlYq4WqK6TIhb5jcpCKTfEM=;\n b=lReweN1qiQByeBls0049oYjNwCgCuZxbviR3dugqdZx9PqiHlJKx534S8mR5VxLnD6\n Y5n/E9LGSOztFx0Es/IcR8IPk1xDcVlz/lhlrIIX6OEF0Q+34aESnSvPzgRVmRrExu7c\n niMrwUie9yQVCdvhlIUPzV5s27o4aIBE78PuvBaPCjZ9BL6FuFSN3oIFsacC7uIsROiE\n 7APzCxTpfqw6SIx9deYzMmC/ywd1PqOdkJWNWDNGVoAPMFub48piupXjjQxkl0OAThDx\n NxVlzQGI6wsSCmSP1UpFdI2binxXmvuV0rQ+u1R1NpI9Q/DByWnX+swxkylsAPKLDcsa\n EVdA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776372346; x=1776977146;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=GwPWif+GAoWQlSDJUgW/WlYq4WqK6TIhb5jcpCKTfEM=;\n b=TBP2fRD/TR6QEsR2MaeqYTlla/w0zzajkxp7bjZFKCVHj07o3dKKNnn0IkDGhPKqvp\n Dp92l2tOph+G+xLKtzdn5WeiDbAwivUw2q0BAr3pYj1Qm734g7Vci4ep7YVOdjqBzU4Q\n 9j6i9aZyuINUBVzo6DLJsT5rF05QGre1TPJ/VUt7WNSi7sLbTXQRFvr8mdqgDDbZwbff\n DSkRSgpznmJhvqXs+4Pfzk5+Ow5KVapRGfcAD8n6qGeIvBjNrzUbDLpKfQqHBqVUcgec\n ggzmfCjWmItQzMBUHEleccXP1lTK/5p7CcOcQ2Uin06qYqbZxyfLGoWNqQrAonhv1Al8\n RTXg==","X-Forwarded-Encrypted":"i=1;\n AFNElJ9fXyRzB145tcydovsJSqjOZK6eJO0WXtCDEVUzry0KYcyO44XYAA0YZ/Kc35/2kWZMgBi+S6+q1XNB@vger.kernel.org","X-Gm-Message-State":"AOJu0YwnNggXvnoI/e12OjzcbybcXnrMe7/9flhKdXRp50/ONQy8jL1Z\n\tOJK6UZaJx6nMrDZfw3ww2Xtb4rQBdO2caIz3yF87xkbXQrS1/s0OJxvk","X-Gm-Gg":"AeBDiesvJLi4pEEwEoiIg2cxivona3FZT7wM1TA34Hyl0Zwq7SLPH25iuHQBphDRlh8\n\tKAi0zSnB5HJ3orzhf+jkrenBA4ce2CGtmSceJfnQI5ALI+j7QJLW0suTC7aXiTEi0KNshhE84o8\n\tzw/IrcOBFx5pAVf6y+iWKAvz9Qi2ahd3KN9kz5OZFE68kJ30xohVqRJXSPC8jhmkqlwdpzjXbHh\n\tFoke2mcLjz9erHyHGbjDBiSPwkNKpC8L4SiOuIFD51Yo5/1FKB7s4LFExgcQzmU+fECkMOvR/1R\n\tOtoy3YQOJj7KGehzxAsFFrZgHowhRvJ1tajakP5armC9r+zxJfpdnAY61rPhmHZVasQgmadt99h\n\tbIDrfMjQNWzoiOdUCd3qwKVLkbRcEmG9eg0SxSVG36qIhunrmE7Bvv2sHgDXtq7g+Nlp0hvxbKv\n\tB9XGd6lbc3JgOwbirjdwbR5xE0ByE=","X-Received":"by 2002:a17:90a:ec85:b0:35f:bd42:c127 with SMTP id\n 98e67ed59e1d1-36140209044mr1959a91.0.1776372346244;\n Thu, 16 Apr 2026 13:45:46 -0700 (PDT)","From":"DaeMyung Kang ","To":"sfrench@samba.org","Cc":"pc@manguebit.org,\n\tronniesahlberg@gmail.com,\n\tsprasad@microsoft.com,\n\ttom@talpey.com,\n\tbharathsm@microsoft.com,\n\trajasimandalos@gmail.com,\n\trajasimandal@microsoft.com,\n\thenrique.carvalho@suse.com,\n\tlinux-cifs@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org,\n\tDaeMyung Kang ","Subject":"[PATCH v3] smb/client: fix state corruption in smb3_reconfigure\n multichannel path","Date":"Fri, 17 Apr 2026 05:45:39 +0900","Message-ID":"<20260416204539.3536168-1-charsyam@gmail.com>","X-Mailer":"git-send-email 2.43.0","In-Reply-To":"<20260416151839.3315696-1-charsyam@gmail.com>","References":"<20260416151839.3315696-1-charsyam@gmail.com>","Precedence":"bulk","X-Mailing-List":"linux-cifs@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Transfer-Encoding":"8bit"},"content":"smb3_reconfigure() has several state-consistency bugs when handling\na multichannel remount that leave ses->chan_max or cifs_sb->ctx\ninconsistent with the actual state. This patch repairs internal\nstate only; the userspace-visible return value of\nsmb3_reconfigure() is preserved to match the pre-patch behaviour:\nthe concurrent-scale loser path still returns -EINVAL, and a\nfailed smb3_update_ses_channels() is not newly propagated to\nuserspace by this patch.\n\nBugs addressed:\n\n1) smb3_sync_ses_chan_max() is called before acquiring\n CIFS_SES_FLAG_SCALE_CHANNELS. If a concurrent operation (e.g.\n smb2_reconnect) holds the flag, the current thread takes the\n loser path and returns -EINVAL, but ses->chan_max has already\n been updated to the new value. chan_max is then out of sync\n with the actual channel state.\n\n2) When smb3_update_ses_channels() fails, ses->chan_max is not\n rolled back. Repeated failures cause chan_max to drift further\n from reality, and subsequent reconnect/reconfigure paths use\n the drifted target.\n\n3) Earlier in smb3_reconfigure(), STEAL_STRING moves UNC, source\n and username from cifs_sb->ctx into ctx, setting\n cifs_sb->ctx->UNC to NULL until smb3_fs_context_dup() copies\n them back near the end of the function. The pre-existing\n CIFS_SES_FLAG_SCALE_CHANNELS loser-path 'return -EINVAL' exits\n inside this window. A loser-path failure therefore permanently\n nulls cifs_sb->ctx->UNC; /proc/mounts shows the device as\n \"none\" and every subsequent mount.cifs-based remount is\n rejected by smb3_verify_reconfigure_ctx() because mount.cifs\n passes that \"none\" back as the new UNC.\n\n4) Once (2) rolls ses->chan_max back to the old value on update\n failure, smb3_fs_context_dup() would still copy the rejected\n new ctx->max_channels into cifs_sb->ctx, creating a fresh\n cifs_sb->ctx vs ses->chan_max mismatch. This must be handled\n together with (2) to keep the rollback complete.\n\nFix all four by:\n\n - Moving smb3_sync_ses_chan_max() after the SCALE_CHANNELS\n acquire so the loser path cannot corrupt chan_max.\n\n - Capturing old_chan_max before the sync and restoring it on\n failure while still holding SCALE_CHANNELS so a concurrent\n reconfigure cannot race with the rollback.\n\n - Recording any multichannel-path failure in a local mchan_rc\n and routing the loser path through a common 'out:' label so\n every exit reaches smb3_fs_context_dup() and cifs_sb->ctx is\n restored. mchan_rc is used only as internal control flow.\n\n - Before the dup, restoring ctx->multichannel and\n ctx->max_channels from cifs_sb->ctx on mchan_rc so the dup\n does not desync cifs_sb->ctx from the already-rolled-back\n ses->chan_max.\n\n - Tracking the concurrent-scale loser path with a separate\n scale_busy flag. After cifs_sb->ctx is fully restored, the\n return value is forced to -EINVAL for that path so userspace\n continues to see the pre-patch rejection. dup /\n dfs_cache_remount_fs() failures still take precedence because\n they reflect real state recovery errors.\n\nDeliberately not changed by this patch: the return value of\nsmb3_reconfigure() on smb3_update_ses_channels() failure. That\npath is not newly propagated to userspace here, matching the\nasynchronous model used by the mount path (mchan_mount_work_fn).\nThose return-semantics and deferred-handling questions are left\nto follow-up discussion/patches.\n\nsmb3_reconfigure() is not fully transactional: ses->password and\nses->password2 are committed before the multichannel block, so\nunrelated earlier state changes may still be visible after a\nfailed multichannel remount. That is a structural property of\nthe function and out of scope here.\n\nTested with a QEMU VM (ksmbd + cifs) using module-parameter\nbased fault injection:\n - Forced smb3_update_ses_channels() failure via module param\n and verified ses->chan_max is preserved at the old value\n after the remount path runs.\n - Pre-set CIFS_SES_FLAG_SCALE_CHANNELS before entering the\n scaling path and verified the loser path still returns\n -EINVAL, no longer corrupts ses->chan_max, and no longer nulls\n cifs_sb->ctx->UNC.\n - Repeated 19 forced-failure remounts with varying max_channels\n (range 2-8) and confirmed no chan_max drift.\n - After each failure path, verified /proc/mounts continues to\n show the original UNC (//127.0.0.1/share) so subsequent\n remounts are accepted.\n\nReported-by: RAJASI MANDAL \nCloses: https://lore.kernel.org/lkml/CAEY6_V1+dzW3OD5zqXhsWyXwrDTrg5tAMGZ1AJ7_GAuRE+aevA@mail.gmail.com/\nLink: https://lore.kernel.org/lkml/xkr2dlvgibq5j6gkcxd3yhhnj4atgxw2uy4eug2pxm7wy7nbms@iq6cf5taa65v/\nFixes: ef529f655a2c (\"cifs: client: allow changing multichannel mount options on remount\")\nSigned-off-by: DaeMyung Kang \n---\nv3: (feedback from Henrique Carvalho)\n - Drop propagation of smb3_update_ses_channels() failure to\n userspace; preserve the pre-patch best-effort semantics on that\n path.\n - Keep the pre-existing CIFS_SES_FLAG_SCALE_CHANNELS loser-path\n -EINVAL via a separate scale_busy flag so that return is not\n silently converted into success.\n - Reword commit message to describe accurately what userspace-\n visible semantics are preserved and what changed internally.\n\nv2: (feedback from Rajasi Mandal)\n - Route loser-path and update-failure exits through a common\n 'out:' label so smb3_fs_context_dup() always runs and\n cifs_sb->ctx->UNC is restored after STEAL_STRING.\n - Restore ctx->multichannel/ctx->max_channels from cifs_sb->ctx\n before the dup so dup does not re-desync cifs_sb->ctx from the\n rolled-back ses->chan_max.\n\n fs/smb/client/fs_context.c | 46 +++++++++++++++++++++++++++++++++-----\n 1 file changed, 41 insertions(+), 5 deletions(-)","diff":"diff --git a/fs/smb/client/fs_context.c b/fs/smb/client/fs_context.c\nindex b9544eb0381b..aaa364a3f60d 100644\n--- a/fs/smb/client/fs_context.c\n+++ b/fs/smb/client/fs_context.c\n@@ -1085,10 +1085,12 @@ static int smb3_reconfigure(struct fs_context *fc)\n \tstruct dentry *root = fc->root;\n \tstruct cifs_sb_info *cifs_sb = CIFS_SB(root->d_sb);\n \tstruct cifs_ses *ses = cifs_sb_master_tcon(cifs_sb)->ses;\n+\tunsigned int old_chan_max;\n \tunsigned int rsize = ctx->rsize, wsize = ctx->wsize;\n \tchar *new_password = NULL, *new_password2 = NULL;\n \tbool need_recon = false;\n-\tint rc;\n+\tbool scale_busy = false;\n+\tint rc, mchan_rc = 0;\n \n \tif (ses->expired_pwd)\n \t\tneed_recon = true;\n@@ -1170,25 +1172,38 @@ static int smb3_reconfigure(struct fs_context *fc)\n \tif ((ctx->multichannel != cifs_sb->ctx->multichannel) ||\n \t (ctx->max_channels != cifs_sb->ctx->max_channels)) {\n \n-\t\t/* Synchronize ses->chan_max with the new mount context */\n-\t\tsmb3_sync_ses_chan_max(ses, ctx->max_channels);\n-\t\t/* Now update the session's channels to match the new configuration */\n \t\t/* Prevent concurrent scaling operations */\n \t\tspin_lock(&ses->ses_lock);\n \t\tif (ses->flags & CIFS_SES_FLAG_SCALE_CHANNELS) {\n \t\t\tspin_unlock(&ses->ses_lock);\n \t\t\tmutex_unlock(&ses->session_mutex);\n-\t\t\treturn -EINVAL;\n+\t\t\tscale_busy = true;\n+\t\t\tmchan_rc = -EINVAL;\n+\t\t\tgoto out;\n \t\t}\n \t\tses->flags |= CIFS_SES_FLAG_SCALE_CHANNELS;\n \t\tspin_unlock(&ses->ses_lock);\n \n+\t\told_chan_max = ses->chan_max;\n+\t\t/* Synchronize ses->chan_max with the new mount context */\n+\t\tsmb3_sync_ses_chan_max(ses, ctx->max_channels);\n+\n \t\tmutex_unlock(&ses->session_mutex);\n \n \t\trc = smb3_update_ses_channels(ses, ses->server,\n \t\t\t\t\t false /* from_reconnect */,\n \t\t\t\t\t false /* disable_mchan */);\n \n+\t\t/*\n+\t\t * On failure, restore chan_max while still holding\n+\t\t * CIFS_SES_FLAG_SCALE_CHANNELS so a concurrent reconfigure\n+\t\t * cannot observe or race with the rollback.\n+\t\t */\n+\t\tif (rc < 0) {\n+\t\t\tsmb3_sync_ses_chan_max(ses, old_chan_max);\n+\t\t\tmchan_rc = rc;\n+\t\t}\n+\n \t\t/* Clear scaling flag after operation */\n \t\tspin_lock(&ses->ses_lock);\n \t\tses->flags &= ~CIFS_SES_FLAG_SCALE_CHANNELS;\n@@ -1197,6 +1212,7 @@ static int smb3_reconfigure(struct fs_context *fc)\n \t\tmutex_unlock(&ses->session_mutex);\n \t}\n \n+out:\n \tSTEAL_STRING(cifs_sb, ctx, domainname);\n \tSTEAL_STRING(cifs_sb, ctx, nodename);\n \tSTEAL_STRING(cifs_sb, ctx, iocharset);\n@@ -1205,6 +1221,16 @@ static int smb3_reconfigure(struct fs_context *fc)\n \tctx->rsize = rsize ? CIFS_ALIGN_RSIZE(fc, rsize) : cifs_sb->ctx->rsize;\n \tctx->wsize = wsize ? CIFS_ALIGN_WSIZE(fc, wsize) : cifs_sb->ctx->wsize;\n \n+\t/*\n+\t * If the multichannel update failed, restore the old multichannel\n+\t * settings in ctx so smb3_fs_context_dup() does not desync\n+\t * cifs_sb->ctx from ses->chan_max (which was already rolled back).\n+\t */\n+\tif (mchan_rc) {\n+\t\tctx->multichannel = cifs_sb->ctx->multichannel;\n+\t\tctx->max_channels = cifs_sb->ctx->max_channels;\n+\t}\n+\n \tsmb3_cleanup_fs_context_contents(cifs_sb->ctx);\n \trc = smb3_fs_context_dup(cifs_sb->ctx, ctx);\n \tsmb3_update_mnt_flags(cifs_sb);\n@@ -1213,6 +1239,16 @@ static int smb3_reconfigure(struct fs_context *fc)\n \t\trc = dfs_cache_remount_fs(cifs_sb);\n #endif\n \n+\t/*\n+\t * Preserve the pre-existing loser-path semantics: a concurrent\n+\t * scaling operation causes the remount to be rejected with\n+\t * -EINVAL. smb3_fs_context_dup() / dfs_cache_remount_fs()\n+\t * failures take precedence because they reflect real state\n+\t * recovery errors. Other multichannel failures remain best-effort.\n+\t */\n+\tif (!rc && scale_busy)\n+\t\trc = -EINVAL;\n+\n \treturn rc;\n }\n \n","prefixes":["v3"]}