[PATCH 1/1] shmem: fix unicode_map leak on remount with casefold=

[PATCH 1/1] shmem: fix unicode_map leak on remount with casefold=

[Mohammed EL Kadiri]

shmem_parse_opt_casefold() calls utf8_load(), which allocates a fresh
struct unicode_map, and stores it in ctx->encoding.

On mount, shmem_fill_super() takes ownership of it via sb->s_encoding,
and shmem_put_super() frees it with utf8_unload().  On remount nothing
takes ownership: shmem_reconfigure() never looks at ctx->encoding, and
shmem_free_fc() only frees ctx itself.  The map is leaked.

50000 x "mount -o remount,casefold=utf8-12.1.0 /t" on a casefolded tmpfs
grows kmalloc-32 from 660 to 50574 active objects, and nothing is
reclaimed on umount.  A tmpfs mounted without casefold stays flat.  With
this patch kmalloc-32 stays flat too.

Clearing ctx->encoding after the transfer is what makes the unload in
shmem_free_fc() safe: otherwise a failure later in mount would free the
same map twice, once via put_super and once via fc->free.  This mirrors
what shmem_reconfigure() already does with ctx->mpol.

This is easy to hit once casefold= is reported in /proc/mounts, since
mount(8) then passes it back on every remount of a casefolded tmpfs.

Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
---
 mm/shmem.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/mm/shmem.c b/mm/shmem.c
index 07b2855dfb7b..49b3cbe0c324 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -5202,6 +5202,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;	/* transfers ownership */
 		set_default_d_op(sb, &shmem_ci_dentry_ops);
 		if (ctx->strict_encoding)
 			sb->s_encoding_flags = SB_ENC_STRICT_MODE_FL;
@@ -5302,6 +5303,10 @@ static void shmem_free_fc(struct fs_context *fc)
 	struct shmem_options *ctx = fc->fs_private;
 
 	if (ctx) {
+#if IS_ENABLED(CONFIG_UNICODE)
+		if (ctx->encoding)
+			utf8_unload(ctx->encoding);
+#endif
 		mpol_put(ctx->mpol);
 		kfree(ctx);
 	}
-- 
2.53.0

Re: [PATCH 1/1] shmem: fix unicode_map leak on remount with casefold=

[Mohammed EL Kadiri]

Missing tag:

Fixes: 58e55efd6c72 ("tmpfs: Add casefold lookup support")

Re: [PATCH 1/1] shmem: fix unicode_map leak on remount with casefold=

[Gabriel Krisman Bertazi]

Mohammed EL Kadiri <med08elkadiri@gmail.com> writes:

> shmem_parse_opt_casefold() calls utf8_load(), which allocates a fresh
> struct unicode_map, and stores it in ctx->encoding.
>
> On mount, shmem_fill_super() takes ownership of it via sb->s_encoding,
> and shmem_put_super() frees it with utf8_unload().  On remount nothing
> takes ownership: shmem_reconfigure() never looks at ctx->encoding, and
> shmem_free_fc() only frees ctx itself.  The map is leaked.
>
> 50000 x "mount -o remount,casefold=utf8-12.1.0 /t" on a casefolded tmpfs
> grows kmalloc-32 from 660 to 50574 active objects, and nothing is
> reclaimed on umount.  A tmpfs mounted without casefold stays flat.  With
> this patch kmalloc-32 stays flat too.
>
> Clearing ctx->encoding after the transfer is what makes the unload in
> shmem_free_fc() safe: otherwise a failure later in mount would free the
> same map twice, once via put_super and once via fc->free.  This mirrors
> what shmem_reconfigure() already does with ctx->mpol.
>
> This is easy to hit once casefold= is reported in /proc/mounts, since
> mount(8) then passes it back on every remount of a casefolded tmpfs.
>
> Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>

Thanks,

I gave this a spin as well and it looks good.  Feel free to add:


Reviewed-by: Gabriel Krisman Bertazi <krisman@suse.de>

Thanks,

-- 
Gabriel Krisman Bertazi

Re: [PATCH 1/1] shmem: fix unicode_map leak on remount with casefold=

[Andrew Morton]

On Tue, 29 Sep 2026 15:13:24 +0200 Mohammed EL Kadiri <med08elkadiri@gmail.com> wrote:

> shmem_parse_opt_casefold() calls utf8_load(), which allocates a fresh
> struct unicode_map, and stores it in ctx->encoding.
> 
> On mount, shmem_fill_super() takes ownership of it via sb->s_encoding,
> and shmem_put_super() frees it with utf8_unload().  On remount nothing
> takes ownership: shmem_reconfigure() never looks at ctx->encoding, and
> shmem_free_fc() only frees ctx itself.  The map is leaked.
> 
> 50000 x "mount -o remount,casefold=utf8-12.1.0 /t" on a casefolded tmpfs
> grows kmalloc-32 from 660 to 50574 active objects, and nothing is
> reclaimed on umount.  A tmpfs mounted without casefold stays flat.  With
> this patch kmalloc-32 stays flat too.
> 
> Clearing ctx->encoding after the transfer is what makes the unload in
> shmem_free_fc() safe: otherwise a failure later in mount would free the
> same map twice, once via put_super and once via fc->free.  This mirrors
> what shmem_reconfigure() already does with ctx->mpol.
> 
> This is easy to hit once casefold= is reported in /proc/mounts, since
> mount(8) then passes it back on every remount of a casefolded tmpfs.

Thanks.

I recently merged
https://lore.kernel.org/20260827152516.805622-1-hnkz.64@gmail.com

Which is preferable?

> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -5202,6 +5202,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;	/* transfers ownership */
>  		set_default_d_op(sb, &shmem_ci_dentry_ops);
>  		if (ctx->strict_encoding)
>  			sb->s_encoding_flags = SB_ENC_STRICT_MODE_FL;
> @@ -5302,6 +5303,10 @@ static void shmem_free_fc(struct fs_context *fc)
>  	struct shmem_options *ctx = fc->fs_private;
>  
>  	if (ctx) {
> +#if IS_ENABLED(CONFIG_UNICODE)
> +		if (ctx->encoding)
> +			utf8_unload(ctx->encoding);
> +#endif
>  		mpol_put(ctx->mpol);
>  		kfree(ctx);
>  	}
> -- 
> 2.53.0

Re: [PATCH 1/1] shmem: fix unicode_map leak on remount with casefold=

[Mohammed EL Kadiri]

On Tue, 29 Sep 2026 13:21:29 -0700 Andrew Morton wrote:
> I recently merged
> https://lore.kernel.org/20260827152516.805622-1-hnkz.64@gmail.com
>
> Which is preferable?

Kazuki's.  It came first and also covers the repeated casefold= leak
I sent separately today, so please drop both of mine:

https://lore.kernel.org/all/3a57ec70731165b4b1244fa89bba95c82a666df8.1790712330.git.med08elkadiri@gmail.com/

Thanks,
Mohammed