From: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>
To: slava@dubeyko.com, glaubitz@physik.fu-berlin.de,
frank.li@vivo.com, brauner@kernel.org, jack@suse.cz,
viro@zeniv.linux.org.uk
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
skhan@linuxfoundation.org, david.hunter.linux@gmail.com,
khalid@kernel.org,
linux-kernel-mentees@lists.linuxfoundation.org,
Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>,
syzbot+ad45f827c88778ff7df6@syzkaller.appspotmail.com
Subject: [PATCH v2] fs/hfs: fix s_fs_info leak on setup_bdev_super() failure
Date: Wed, 19 Nov 2025 08:38:20 +0100 [thread overview]
Message-ID: <20251119073845.18578-1-mehdi.benhadjkhelifa@gmail.com> (raw)
The regression introduced by commit aca740cecbe5 ("fs: open block device
after superblock creation") allows setup_bdev_super() to fail after a new
superblock has been allocated by sget_fc(), but before hfs_fill_super()
takes ownership of the filesystem-specific s_fs_info data.
In that case, hfs_put_super() and the failure paths of hfs_fill_super()
are never reached, leaving the HFS mdb structures attached to s->s_fs_info
unreleased.The default kill_block_super() teardown also does not free
HFS-specific resources, resulting in a memory leak on early mount failure.
Fix this by moving all HFS-specific teardown (hfs_mdb_put()) from
hfs_put_super() and the hfs_fill_super() failure path into a dedicated
hfs_kill_sb() implementation. This ensures that both normal unmount and
early teardown paths (including setup_bdev_super() failure) correctly
release HFS metadata.
This also preserves the intended layering: generic_shutdown_super()
handles VFS-side cleanup, while HFS filesystem state is fully destroyed
afterwards.
Fixes: aca740cecbe5 ("fs: open block device after superblock creation")
Reported-by: syzbot+ad45f827c88778ff7df6@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ad45f827c88778ff7df6
Tested-by: syzbot+ad45f827c88778ff7df6@syzkaller.appspotmail.com
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>
---
ChangeLog:
Changes from v1:
-Changed the patch direction to focus on hfs changes specifically as
suggested by al viro
Link:https://lore.kernel.org/all/20251114165255.101361-1-mehdi.benhadjkhelifa@gmail.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 and test it with syzbot as well.
fs/hfs/super.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/fs/hfs/super.c b/fs/hfs/super.c
index 47f50fa555a4..06e1c25e47dc 100644
--- a/fs/hfs/super.c
+++ b/fs/hfs/super.c
@@ -49,8 +49,6 @@ static void hfs_put_super(struct super_block *sb)
{
cancel_delayed_work_sync(&HFS_SB(sb)->mdb_work);
hfs_mdb_close(sb);
- /* release the MDB's resources */
- hfs_mdb_put(sb);
}
static void flush_mdb(struct work_struct *work)
@@ -383,7 +381,6 @@ static int hfs_fill_super(struct super_block *sb, struct fs_context *fc)
bail_no_root:
pr_err("get root inode failed\n");
bail:
- hfs_mdb_put(sb);
return res;
}
@@ -431,10 +428,21 @@ static int hfs_init_fs_context(struct fs_context *fc)
return 0;
}
+static void hfs_kill_sb(struct super_block *sb)
+{
+ generic_shutdown_super(sb);
+ hfs_mdb_put(sb);
+ if (sb->s_bdev) {
+ sync_blockdev(sb->s_bdev);
+ bdev_fput(sb->s_bdev_file);
+ }
+
+}
+
static struct file_system_type hfs_fs_type = {
.owner = THIS_MODULE,
.name = "hfs",
- .kill_sb = kill_block_super,
+ .kill_sb = hfs_kill_sb,
.fs_flags = FS_REQUIRES_DEV,
.init_fs_context = hfs_init_fs_context,
};
--
2.52.0
next reply other threads:[~2025-11-19 6:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 7:38 Mehdi Ben Hadj Khelifa [this message]
2025-11-19 14:14 ` [PATCH v2] fs/hfs: fix s_fs_info leak on setup_bdev_super() failure Christian Brauner
2025-11-19 15:27 ` Mehdi Ben Hadj Khelifa
2025-11-19 19:58 ` Viacheslav Dubeyko
2025-11-19 22:21 ` Mehdi Ben Hadj Khelifa
2025-11-19 22:24 ` Mehdi Ben Hadj Khelifa
2025-11-21 19:44 ` Mehdi Ben Hadj Khelifa
2025-11-21 21:15 ` Viacheslav Dubeyko
2025-11-21 22:48 ` Mehdi Ben Hadj Khelifa
2025-11-21 22:04 ` Viacheslav Dubeyko
2025-11-21 23:16 ` Mehdi Ben Hadj Khelifa
2025-11-21 22:28 ` Viacheslav Dubeyko
2025-11-21 23:36 ` Mehdi Ben Hadj Khelifa
2025-11-21 23:01 ` Viacheslav Dubeyko
2025-11-25 22:14 ` Mehdi Ben Hadj Khelifa
2025-11-25 22:36 ` Viacheslav Dubeyko
2025-11-27 17:45 ` David Hunter
2025-11-29 13:06 ` Mehdi Ben Hadj Khelifa
2025-11-26 13:48 ` Christian Brauner
2025-11-26 16:06 ` Mehdi Ben Hadj Khelifa
2025-11-26 22:30 ` Viacheslav Dubeyko
2025-11-27 8:59 ` Christian Brauner
2025-11-27 20:19 ` Viacheslav Dubeyko
2025-11-29 12:48 ` Mehdi Ben Hadj Khelifa
2025-12-01 19:24 ` Viacheslav Dubeyko
2025-12-01 21:19 ` Mehdi Ben Hadj Khelifa
2025-12-01 20:37 ` Viacheslav Dubeyko
2025-12-01 21:57 ` Mehdi Ben Hadj Khelifa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251119073845.18578-1-mehdi.benhadjkhelifa@gmail.com \
--to=mehdi.benhadjkhelifa@gmail.com \
--cc=brauner@kernel.org \
--cc=david.hunter.linux@gmail.com \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=jack@suse.cz \
--cc=khalid@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=slava@dubeyko.com \
--cc=syzbot+ad45f827c88778ff7df6@syzkaller.appspotmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).