Re: [PATCH] fs/super: fix s_fs_info leak when setup_bdev_super() fails

[Al Viro <viro@zeniv.linux.org.uk>]

On Sun, Feb 01, 2026 at 01:02:26PM +0530, Shardul Bankar wrote:

> In get_tree_bdev_flags(), sget_dev() calls sget_fc(), which transfers
> ownership of fc->s_fs_info to the new superblock (s->s_fs_info) and
> clears fc->s_fs_info. If setup_bdev_super() then fails, the superblock
> is torn down via deactivate_locked_super(). However,
> generic_shutdown_super() only calls the filesystem's ->put_super()
> when sb->s_root is non-NULL. Since setup_bdev_super() fails before
> fill_super() runs, sb->s_root is never set, so ->put_super() is never
> called and the allocated s_fs_info is leaked.
> 
> Return ownership of s_fs_info to fc when setup_bdev_super() fails so
> put_fs_context() can free it via the filesystem's ->free() callback.
> Clear s->s_fs_info to avoid a stale reference. Do this only when
> setup_bdev_super() fails; when fill_super() fails, it already frees
> s_fs_info in its own error path.

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().

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.