Re: [PATCH v2 1/8] smb: client: sync runtime state into ctx on reconfigure

> @@ -1961,6 +2112,48 @@ int smb3_init_fs_context(struct fs_context *fc)
>         char *nodename = utsname()->nodename;
>         int i;
>
> +       /*
> +        * For reconfigure (remount), duplicate the existing mount context
> +        * instead of building one from scratch with init defaults.
> +        *
> +        * VFS sets fc->root before calling init_fs_context for reconfigure,
> +        * so we can access the existing superblock's context.  We dup the
> +        * live cifs_sb->ctx into a private new_ctx, then sync new_ctx with
> +        * runtime state (tcon/server/ses) so it matches what
> +        * cifs_show_options() displays.  Syncing into the private copy (not
> +        * the shared cifs_sb->ctx) avoids racing with concurrent
> +        * fspick/remount and /proc/mounts readers.  The parser will overwrite
> +        * only the options explicitly passed on remount, so any difference
> +        * between new_ctx and old_ctx in smb3_verify_reconfigure_ctx()
> +        * represents a real, intentional change by the user.
> +        */
> +       if (fc->purpose == FS_CONTEXT_FOR_RECONFIGURE) {
> +               struct cifs_sb_info *cifs_sb = CIFS_SB(fc->root->d_sb);
> +               int rc;
> +
> +               ctx = kzalloc_obj(struct smb3_fs_context);
> +               if (!ctx)
> +                       return -ENOMEM;
> +
> +               rc = smb3_fs_context_dup(ctx, cifs_sb->ctx);
Doesn't this add another potential UAF path? smb3_init_fs_context()
may run before  s_umount is acquired, so this duplication could race
with another remount freeing or replacing strings in cifs_sb->ctx.