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

Message-ID: <86897b3b-23b7-400a-b8d6-4169e78bf5d9@gmail.com>
Date: Tue, 18 Nov 2025 19:05:44 +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 5:55 PM, Al Viro wrote:
> On Tue, Nov 18, 2025 at 04:35:09PM +0000, Al Viro wrote:
> 


>> For HFS I would expect that hfs_fill_super() would call hfs_mdb_put(sb)
>> on all failures and have it called from subsequent ->put_super() if
>> we succeed and later unmount the filesystem.  That seems to be where
>> ->s_fs_info is taken out of superblock and freed.
>>
>> What do you observe getting leaked and in which case does that happen?
Sorry for my other late reply. My thunderbird client had some issues and 
got delayed and seperated emails somehow...
> 
> AFAICS, the problem is with aca740cecbe5 "fs: open block device after superblock
> creation" where you get a failure exit stuck between getting a new superblock
> from sget_fc() and calling fill_super().
> 

Yes this is what I mentionned in my earlier mail.(not the commit causing 
the issue though).
> That is where the gap has been introduced.  I see two possible solutions:
> one is to have failure of setup_bdev_super() (and only it) steal ->s_fs_info
> back, on the theory that filesystem didn't have a chance to do anything
> yet.  Another is to move the call of hfs_mdb_put() from failure exits of
> hfs_fill_super() *and* from hfs_put_super() into hfs_kill_sb(), that
> would do that:
> 
> 	generic_shutdown_super(sb);
> 	hfs_mdb_put(sb);
> 	if (sb->s_bdev) {
> 		sync_blockdev(sb->s_bdev);
> 		bdev_fput(sb->s_bdev_file);
> 	}

I will do the second approach, test it send it for review shortly.

Best regards,
Mehdi Ben Hadj Khelifa