All of lore.kernel.org
 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 v2] adfs: fix memory leak in sb->s_fs_info
Date: Mon, 15 Dec 2025 01:55:00 +0000	[thread overview]
Message-ID: <20251215015500.GM1712166@ZenIV> (raw)
In-Reply-To: <20251215002252.158637-2-eraykrdg1@gmail.com>

On Mon, Dec 15, 2025 at 03:22:52AM +0300, Ahmet Eray Karadag wrote:

> @@ -403,15 +394,9 @@ static int adfs_fill_super(struct super_block *sb, struct fs_context *fc)
>  	if (!sb->s_root) {
>  		adfs_free_map(sb);
>  		adfs_error(sb, "get root inode failed\n");
> -		ret = -EIO;
> -		goto error;
> +		return -EIO;

Double-free again, this time of asb->s_map - adfs_free_map() is called
twice in that case, once here and once in adfs_kill_sb()...

> +static void adfs_kill_sb(struct super_block *sb)
> +{
> +	struct adfs_sb_info *asb = ADFS_SB(sb);
> +
> +	kill_block_super(sb);
> +
> +	adfs_free_map(sb);

... and calling adfs_map_relse(), which calls brelse() after the block
device has been closed.  IOW, unlike freeing the ->s_fs_info this can't
be done after kill_block_super().  And with this one we don't have that
kind of gap - it doesn't exist until adfs_fill_super(), so there's no
leak to be had anyway.  Yes, it would be possible to get rid of more
of cleanup on failure exit there, but it would require expanding
kill_block_super() and inserting adfs_free_map() call before the call
sync_blockdev() in there - more headache than you win in adfs_fill_super(),
IMO.

Leave adfs_free_map() in adfs_put_super() (or make _it_ ->put_super(),
for that matter).

  reply	other threads:[~2025-12-15  1:54 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
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 [this message]
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=20251215015500.GM1712166@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.