linux-kernel - Re: [PATCH] fs/super: fix memory leak of s_fs_info on setup_bdev

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: <6c482108-78b8-4e09-814a-67820a5c021e@gmail.com>
Date: Tue, 18 Nov 2025 17:21:59 +0100
From: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@...il.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: brauner@...nel.org, jack@...e.cz,
 syzbot+ad45f827c88778ff7df6@...kaller.appspotmail.com, frank.li@...o.com,
 glaubitz@...sik.fu-berlin.de, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, slava@...eyko.com,
 syzkaller-bugs@...glegroups.com, skhan@...uxfoundation.org,
 david.hunter.linux@...il.com, khalid@...nel.org,
 linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH] fs/super: fix memory leak of s_fs_info on
 setup_bdev_super failure

On 11/18/25 3:59 PM, Al Viro wrote:
> On Fri, Nov 14, 2025 at 05:52:27PM +0100, Mehdi Ben Hadj Khelifa wrote:
>> Failure in setup_bdev_super() triggers an error path where
>> fc->s_fs_info ownership has already been transferred to the superblock via
>> sget_fc() call in get_tree_bdev_flags() and calling put_fs_context() in
>> do_new_mount() to free the s_fs_info for the specific filesystem gets
>> passed in a NULL pointer.
>>
>> Pass back the ownership of the s_fs_info pointer to the filesystem context
>> once the error path has been triggered to be cleaned up gracefully in
>> put_fs_context().
>>
>> Fixes: cb50b348c71f ("convenience helpers: vfs_get_super() and sget_fc()")
>> Reported-by: syzbot+ad45f827c88778ff7df6@...kaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=ad45f827c88778ff7df6
>> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@...il.com>
>> ---
>> Note:This patch might need some more testing as I only did run selftests
>> with no regression, check dmesg output for no regression, run reproducer
>> with no bug.
> 
> Almost certainly bogus; quite a few fill_super() callbacks seriously count
> upon "->kill_sb() will take care care of cleanup if we return an error".

So should I then free the allocated s_fs_info in the kill_block_super 
instead and check for the null pointer in put_fs_context to not execute 
kfree in subsequent call to hfs_free_fc()?

Because the error generated in setup_bdev_super() when returned to 
do_new_mount() (after a lot of error propagation) it doesn't get handled:	
	if (!err)
		err = do_new_mount_fc(fc, path, mnt_flags);
	put_fs_context(fc);
	return err;

Also doesn't get handled anywhere in the call stack after IIUC:

In path_mount:
	return do_new_mount(path, type_page, sb_flags, mnt_flags, dev_name,
			    data_page);

In do_mount:
	return path_mount(dev_name, &path, type_page, flags, data_page);

So what is recommended in this case ?

Best Regards,
Mehdi Ben Hadj Khelifa