linux-kernel - Re: [PATCH] efivarfs: Suppress false-positive kmemleak warning for sfi

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <a3d063f4b0ccaad7595938ea0dca016872882f0d.camel@HansenPartnership.com>
Date: Wed, 16 Jul 2025 08:31:04 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Breno Leitao <leitao@...ian.org>, Ard Biesheuvel <ardb@...nel.org>
Cc: Jeremy Kerr <jk@...abs.org>, linux-efi@...r.kernel.org, 
	linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH] efivarfs: Suppress false-positive kmemleak warning for
 sfi

On Wed, 2025-07-16 at 04:45 -0700, Breno Leitao wrote:
> On Wed, Jul 16, 2025 at 10:41:24AM +1000, Ard Biesheuvel wrote:
> > On Tue, 15 Jul 2025 at 19:31, Breno Leitao <leitao@...ian.org>
> > wrote:
> > > 
> > > When kmemleak is enabled, it incorrectly reports the sfi
> > > structure allocated during efivarfs_init_fs_context() as leaked:
> > > 
> > >     unreferenced object 0xffff888146250b80 (size 64):
> > >     __kmalloc_cache_noprof
> > >     efivarfs_init_fs_context
> > >     ...
> > > 
> > > On module unload, this object is freed in efivarfs_kill_sb(),
> > > confirming no actual leak. Also, kfree(sfi) is called at
> > > efivarfs_kill_sb(). I am not able to explain why kmemleak
> > > detected it as a leak. To silence this false-positive, mark the
> > > sfi allocation as ignored by kmemleak right after allocation.
> > > 
> > > This ensures clearer leak diagnostics for this allocation path.
> > > 
> > 
> > Can you provide a reproducer? x86 defconfig with kmemleak enabled
> > does not show this behavior.
> 
> I see this problem all the time when mounting efivars. This is the
> config I am using: https://pastebin.com/i21Yv0jt

Actually, there is a way this could be happening: to process the
options, we have to allocate sfi early when the fs_context is
initialized, but it is actually a property of the superblock and is
freed when the superblock is killed.  If we got a situation where
something did a final put of the fs context before we get to fill_super
(which is where the handover happens) we would leak sfi's.  This would
have to be on an error leg I presume (or possibly a reconfigure looking
at the code).

If the theory is correct, the leak is genuine and we need to implement
.free in efivarfs_context_ops to fix it.

Regards,

James