mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gabriel Krisman Bertazi <gabriel@krisman.be>
To: Kazuki Hanai <hnkz.64@gmail.com>, hughd@google.com
Cc: baolin.wang@linux.alibaba.com, akpm@linux-foundation.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Kazuki Hanai <hnkz.64@gmail.com>
Subject: Re: [PATCH v2] tmpfs: fix unicode_map leaks in casefold option handling
Date: Tue, 29 Sep 2026 17:09:34 -0400	[thread overview]
Message-ID: <874if7ydbl.fsf@mailhost.krisman.be> (raw)
In-Reply-To: <20260827152516.805622-1-hnkz.64@gmail.com>

Kazuki Hanai <hnkz.64@gmail.com> writes:

> shmem_parse_opt_casefold() stores the unicode_map returned by
> utf8_load() in ctx->encoding. The casefold parameter can be supplied
> more than once for the same filesystem context, but replacing the
> stored map does not release the previous reference.
>
> The final reference is also leaked when an unmounted filesystem
> context is freed.
>
> Release the previous map before replacing it, clear ctx->encoding
> after transferring ownership to the superblock, and release any
> remaining reference from shmem_free_fc().
>
> An unprivileged user can repeatedly set the casefold parameter on a
> tmpfs filesystem context from a user namespace. This causes
> unbounded kernel memory consumption and can result in a local denial
> of service.
>
> Fixes: 58e55efd6c72 ("tmpfs: Add casefold lookup support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Kazuki Hanai <hnkz.64@gmail.com>
> ---
> Changes in v2:
> - Keep Fixes, Cc, and Signed-off-by in a single trailer block.
>
>  mm/shmem.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 89a1495e55f7..62440caf2df5 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -4508,6 +4508,7 @@ static int shmem_parse_opt_casefold(struct fs_context *fc, struct fs_parameter *
>  	pr_info("tmpfs: Using encoding : utf8-%u.%u.%u\n",
>  		unicode_major(version), unicode_minor(version), unicode_rev(version));
>  
> +	utf8_unload(ctx->encoding);
>  	ctx->encoding = encoding;

This patch fixes two bugs at once, as shown by the other patchset that
does it separately. One is the leak during 'mount -o remount', fixed by
the second hunk, which is fine.  The other is when multiple casefold=
parameters are passed at once.  I think that fix is wrong.

I can't think of a real case where it makes sense to pass multiple
casefold parameters, besides user error.  even if you are trying to
outsmart the kernel and handle cases where a new encoding might not be
available, giving it a fallback version, a failure in the first
utf8_load will back off the mount.  IMO, we should just reject the mount
right away instead of silently swallowing the first table here.

This hunk should have been something like this instead:

diff --git a/mm/shmem.c b/mm/shmem.c
index e46bd4fc7e41..06503858dae4 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -4506,6 +4506,9 @@ static int shmem_parse_opt_casefold(struct fs_context *fc, struct fs_parameter *
 	struct unicode_map *encoding;
 	char *version_str = param->string + 5;
 
+	if (ctx->encoding)
+		return invalfc(fc, "casefold parameter cannot be specified twice\n");
+
 	if (!latest_version) {
 		if (strncmp(param->string, "utf8-", 5))
 			return invalfc(fc, "Only UTF-8 encodings are supported "

> @@ -4976,6 +4977,7 @@ static int shmem_fill_super(struct super_block *sb, struct fs_context *fc)
>  
>  	if (ctx->encoding) {
>  		sb->s_encoding = ctx->encoding;
> +		ctx->encoding = NULL;
>  		set_default_d_op(sb, &shmem_ci_dentry_ops);
>  		if (ctx->strict_encoding)
>  			sb->s_encoding_flags = SB_ENC_STRICT_MODE_FL;
> @@ -5073,6 +5075,9 @@ static void shmem_free_fc(struct fs_context *fc)
>  	struct shmem_options *ctx = fc->fs_private;
>  
>  	if (ctx) {
> +#if IS_ENABLED(CONFIG_UNICODE)
> +		utf8_unload(ctx->encoding);
> +#endif
>  		mpol_put(ctx->mpol);
>  		kfree(ctx);
>  	}
> -- 
> 2.53.0

This part looks fine.


-- 
Gabriel Krisman Bertazi

      parent reply	other threads:[~2026-09-29 21:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27 15:14 [PATCH] " Kazuki Hanai
2026-08-27 15:25 ` [PATCH v2] " Kazuki Hanai
2026-08-27 17:29   ` Andrew Morton
2026-09-29 21:09   ` Gabriel Krisman Bertazi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874if7ydbl.fsf@mailhost.krisman.be \
    --to=gabriel@krisman.be \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=hnkz.64@gmail.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®