Linux filesystem development
 help / color / mirror / Atom feed
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().

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox