From: Al Viro <viro@zeniv.linux.org.uk>
To: Ahmet Eray Karadag <eraykrdg1@gmail.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, skhan@linuxfoundation.org,
david.hunter.linux@gmail.com,
syzbot+1c70732df5fd4f0e4fbb@syzkaller.appspotmail.com
Subject: Re: [PATCH] adfs: fix memory leak in sb->s_fs_info
Date: Sun, 14 Dec 2025 02:02:12 +0000 [thread overview]
Message-ID: <20251214020212.GJ1712166@ZenIV> (raw)
In-Reply-To: <20251214013249.GI1712166@ZenIV>
On Sun, Dec 14, 2025 at 01:32:49AM +0000, Al Viro wrote:
> Question: if that thing is leaking all the time, why hadn't that been caught
> earlier?
>
> Question: does it really leak all the time? How would one check that?
>
> Question: if it does not leak in each and every case, presumably the damn thing
> does get freed at some point; where would that be?
>
> Question: would we, by any chance, run into a double-free with that "fix"?
>
>
> Please, do yourself a favour and find answers to the questions above.
> They are fairly trivial and it is the kind of exercise one has to do every
> time when dealing with something of that sort.
<spoiler alert>
\f
A trivial experiment would be to mount a valid image, unmount it and see
if anything has leaked. Finding a valid image is not hard - the second
hit when googling for "ADFS image acorn" is a github-hosted project
and right in there there's a directory called "ADFS Test Images", with
expected contents. Whether it's legitimate or not, mounting it in a kernel
that runs under unpriveleged qemu ought to be safe enough.
And no, it doesn't leak on mount + umount
Looking for places where it could be freed in normal operation is also
not terribly hard - looking for kfree() in fs/adfs/super.c catches three
hits:
1) in adfs_put_super() we see
struct adfs_sb_info *asb = ADFS_SB(sb);
adfs_free_map(sb);
kfree_rcu(asb, rcu);
2) in the end of adfs_fill_super() there's
error:
sb->s_fs_info = NULL;
kfree(asb);
return ret;
3) in adfs_free_fc() we have
struct adfs_context *asb = fc->s_fs_info;
kfree(asb);
#2 and #3 are obviously irrelevant for the case of normal mount + umount -
adfs_fill_super() has already run at mount time (and did not hit error:)
and so did adfs_free_fc().
So we have #1 to look into. adfs_put_super() is never called directly and
it's only reached as a member of struct super_operations adfs_sops -
something called 'put_super'. Where would that method be called?
grep and you shall find it:
void generic_shutdown_super(struct super_block *sb)
{
const struct super_operations *sop = sb->s_op;
if (sb->s_root) {
...
if (sop->put_super)
sop->put_super(sb);
So it is called by generic_shutdown_super() in case if ->s_root had not
been NULL. Looking for callers of generic_shutdown_super() immediately
catches
void kill_block_super(struct super_block *sb)
{
struct block_device *bdev = sb->s_bdev;
generic_shutdown_super(sb);
if (bdev) {
sync_blockdev(bdev);
bdev_fput(sb->s_bdev_file);
}
}
so it is called by adfs ->kill_sb() - both the current mainline and with
that patch.
IOW, there's our double-free. For extra fun, it's not just kfree() + kfree(),
it's kfree_rcu() + kfree().
next prev parent reply other threads:[~2025-12-14 2:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-13 23:36 [PATCH] adfs: fix memory leak in sb->s_fs_info Ahmet Eray Karadag
2025-12-14 1:32 ` Al Viro
2025-12-14 2:02 ` Al Viro [this message]
2025-12-14 2:27 ` Al Viro
2025-12-14 2:58 ` Ahmet Eray Karadag
2025-12-15 0:22 ` [PATCH v2] " Ahmet Eray Karadag
2025-12-15 1:55 ` Al Viro
2025-12-15 3:14 ` [PATCH v3] " Ahmet Eray Karadag
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=20251214020212.GJ1712166@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=david.hunter.linux@gmail.com \
--cc=eraykrdg1@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=syzbot+1c70732df5fd4f0e4fbb@syzkaller.appspotmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.