linux-kernel - Re: [PATCH v2] efivarfs: Fix memory leak of efivarfs_fs_info in fs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMj1kXFLE+9OsYJepxm0seHREvFB52VvjcQrRnQoSAT9Aoe1Mw@mail.gmail.com>
Date: Fri, 18 Jul 2025 20:00:51 +1000
From: Ard Biesheuvel <ardb@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Jeremy Kerr <jk@...abs.org>, Matthew Garrett <mgarrett@...ora.tech>, Jiao Zhou <jiaozhou@...gle.com>, 
	linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com, 
	James Bottomley <James.Bottomley@...senpartnership.com>
Subject: Re: [PATCH v2] efivarfs: Fix memory leak of efivarfs_fs_info in
 fs_context error paths

On Thu, 17 Jul 2025 at 01:23, Breno Leitao <leitao@...ian.org> wrote:
>
> When processing mount options, efivarfs allocates efivarfs_fs_info (sfi)
> early in fs_context initialization. However, sfi is associated with the
> superblock and typically freed when the superblock is destroyed. If the
> fs_context is released (final put) before fill_super is called—such as
> on error paths or during reconfiguration—the sfi structure would leak,
> as ownership never transfers to the superblock.
>
> Implement the .free callback in efivarfs_context_ops to ensure any
> allocated sfi is properly freed if the fs_context is torn down before
> fill_super, preventing this memory leak.
>
> Suggested-by: James Bottomley <James.Bottomley@...senPartnership.com>
> Fixes: 5329aa5101f73c ("efivarfs: Add uid/gid mount options")
> Signed-off-by: Breno Leitao <leitao@...ian.org>
> ---
> Changes in v2:
> - instead of silenting the warning, just fix the problem.
> - Link to v1: https://lore.kernel.org/r/20250715-kmemleak_efi-v1-1-c07e68c76ae8@debian.org
> ---
>  fs/efivarfs/super.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>

Queued as a fix - thanks.



> diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
> index c900d98bf4945..284d6dbba2ece 100644
> --- a/fs/efivarfs/super.c
> +++ b/fs/efivarfs/super.c
> @@ -390,10 +390,16 @@ static int efivarfs_reconfigure(struct fs_context *fc)
>         return 0;
>  }
>
> +static void efivarfs_free(struct fs_context *fc)
> +{
> +       kfree(fc->s_fs_info);
> +}
> +
>  static const struct fs_context_operations efivarfs_context_ops = {
>         .get_tree       = efivarfs_get_tree,
>         .parse_param    = efivarfs_parse_param,
>         .reconfigure    = efivarfs_reconfigure,
> +       .free           = efivarfs_free,
>  };
>
>  static int efivarfs_check_missing(efi_char16_t *name16, efi_guid_t vendor,
>
> ---
> base-commit: 8c2e52ebbe885c7eeaabd3b7ddcdc1246fc400d2
> change-id: 20250714-kmemleak_efi-bedfe48a304d
>
> Best regards,
> --
> Breno Leitao <leitao@...ian.org>
>