linux-kernel - Re: [PATCH] adfs: fix memory leak in sb->s_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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251214013249.GI1712166@ZenIV>
Date: Sun, 14 Dec 2025 01:32:49 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Ahmet Eray Karadag <eraykrdg1@...il.com>
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, skhan@...uxfoundation.org,
	david.hunter.linux@...il.com,
	syzbot+1c70732df5fd4f0e4fbb@...kaller.appspotmail.com
Subject: Re: [PATCH] adfs: fix memory leak in sb->s_fs_info

On Sun, Dec 14, 2025 at 02:36:22AM +0300, Ahmet Eray Karadag wrote:
> Syzbot reported a memory leak in adfs during the mount process. The issue
> arises because the ownership of the allocated (struct adfs_sb_info) is
> transferred from the filesystem context to the superblock via sget_fc().
> This function sets fc->s_fs_info to NULL after the transfer.
> 
> The ADFS filesystem previously used the default kill_block_super for
> superblock destruction. This helper performs generic cleanup but does not
> free the private sb->s_fs_info data. Since fc->s_fs_info is set to
> NULL during the transfer, the standard context cleanup (adfs_free_fc)
> also skips freeing this memory. As a result, if the superblock is
> destroyed, the allocated struct adfs_sb_info is leaked.
> 
> Fix this by implementing a custom .kill_sb callback (adfs_kill_sb)
> that explicitly frees sb->s_fs_info before invoking the generic
> kill_block_super.

I hate dealing with humans in the way one would deal with a chatbot, but...

Question: if that thing is leaking all the time, why hadn't that been caught
earlier?

Question: does it really leak all the time?  How would one check that?

Question: if it does not leak in each and every case, presumably the damn thing
does get freed at some point; where would that be?

Question: would we, by any chance, run into a double-free with that "fix"?

Please, do yourself a favour and find answers to the questions above.
They are fairly trivial and it is the kind of exercise one has to do every
time when dealing with something of that sort.