linux-kernel - Re: [PATCH] fs/super: fix s_fs_info leak when 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: <5edc62f11796c116fb499fe2934c487f087a2cdd.camel@mpiricsoftware.com>
Date: Sun, 01 Feb 2026 17:09:44 +0530
From: Shardul Bankar <shardul.b@...ricsoftware.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: brauner@...nel.org, jack@...e.cz, linux-fsdevel@...r.kernel.org, 
 linux-kernel@...r.kernel.org, janak@...ricsoftware.com, slava@...eyko.com, 
 syzbot+99f6ed51479b86ac4c41@...kaller.appspotmail.com, shardulsb08@...il.com
Subject: Re: [PATCH] fs/super: fix s_fs_info leak when setup_bdev_super()
 fails

On Sun, 2026-02-01 at 08:27 +0000, Al Viro wrote:
> On Sun, Feb 01, 2026 at 01:02:26PM +0530, Shardul Bankar wrote:
> 
> 
> First of all, _what_ ->put_super()?  Forget ->s_root, ->s_op is
> not going to be set there, so there's nowhere to get ->put_super()
> from.  Relevant thing here is ->kill_sb().
> 
Right, good catch- at that point ->s_op isn’t set yet, so ->put_super()
isn’t even a thing to rely on. Thanks for pointing that out.

The leak here is actually originating from hfsplus
(hfsplus_init_fs_context()).

> Freeing ->s_fs_info is better done there anyway - makes for simpler
> handling of foo_fill_super() failure exits, exactly because you don't
> need to free the damn thing there - just let your ->kill_sb() deal
> with
> it.
> 
> The thing is, there are ->kill_sb() instances that do just that and
> I'm not at all sure they won't be broken by this patch.
> 
> Note that right now it's either "deactivate_locked_super() done, -
> >free()
> is told to bugger off" or "->free() is called,
> deactivate_locked_super()
> and ->kill_sb() isn't"; you are introducing a new situation here.

I see your concern about introducing a new ownership state for
s_fs_info (handing it back to fc while still going through
deactivate_locked_super() / ->kill_sb()), which could break filesystems
that already free s_fs_info from ->kill_sb().

I'll drop this patch and raise a new one by fixing the leak in the
filesystem side instead (HFS+), making sure its ->kill_sb() path
reliably frees s_fs_info even when we fail before fill_super() runs,
and I’ll add the HFS+ maintainer(s) on that patch.

Thanks,
Shardul