All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Daniel Yang <danielyangkang@gmail.com>
Cc: Namjae Jeon <linkinjeon@kernel.org>,
	Sungjong Seo <sj1557.seo@samsung.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzbot+e1c69cadec0f1a078e3d@syzkaller.appspotmail.com
Subject: Re: [PATCH] fs/exfat: resolve memory leak from exfat_create_upcase_table()
Date: Sun, 15 Sep 2024 08:23:36 +0100	[thread overview]
Message-ID: <20240915072336.GF2825852@ZenIV> (raw)
In-Reply-To: <20240915070546.GE2825852@ZenIV>

On Sun, Sep 15, 2024 at 08:05:46AM +0100, Al Viro wrote:

> 	Interesting...  How does the mainline manage to avoid the
> call of exfat_kill_sb(), which should call_rcu() delayed_free(), which
> calls exfat_free_upcase_table()?
> 
> 	Could you verify that your reproducer does *NOT* hit that
> callchain?  AFAICS, the only caller of exfat_load_upcase_table()
> is exfat_create_upcase_table(), called by __exfat_fill_super(),
> called by exfat_fill_super(), passed as callback to get_tree_bdev().
> And if that's the case, ->kill_sb() should be called on failure and
> with non-NULL ->s_fs_info...
> 
> 	Something odd is going on there.

	Yecchh...  OK, I see what's happening, and the patch is probably
correct, but IMO it's way too subtle.  Unless I'm misreading what's
going on there, you have the following:
	exfat_load_upcase_table() have 3 failure exits.

One of them is with -ENOMEM; no table allocated and we proceed to
exfat_load_default_upcase_table().

Another is with -EIO.  In that case the table is left allocated, the
caller of exfat_load_upcase_table() returns immediately and the normal
logics in ->kill_sb() takes it out.

Finally, there's one with -EINVAL.  There the caller proceeds to
exfat_load_default_upcase_table(), which is where the mainline leaks.
That's the case your patch adjusts.

Note that resulting rules for exfat_load_upcase_table()
	* should leave for ->kill_sb() to free if failing with -EIO.
	* should make sure it's freed on all other failure exits.

At the very least that needs to be documented.  However, since the
problem happens when the caller proceeds to exfat_load_default_upcase_table(),
the things would be simpler if you had taken the "need to free what we'd
allocated" logics into the place where that logics is visible.  I.e.

                        ret = exfat_load_upcase_table(sb, sector, num_sectors,
                                le32_to_cpu(ep->dentry.upcase.checksum));

                        brelse(bh);
                        if (ret && ret != -EIO) {
				/* clean after exfat_load_upcase_table() */
				exfat_free_upcase_table(sbi);
                                goto load_default;
			}
IMO it would be less brittle that way.  And commit message needs
the explanation of the leak mechanism - a link to reporter is
nice, but it doesn't explain what's going on.

  reply	other threads:[~2024-09-15  7:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-15  6:44 [PATCH] fs/exfat: resolve memory leak from exfat_create_upcase_table() Daniel Yang
2024-09-15  7:05 ` Al Viro
2024-09-15  7:23   ` Al Viro [this message]
2024-09-15  7:26     ` Al Viro

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=20240915072336.GF2825852@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=danielyangkang@gmail.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sj1557.seo@samsung.com \
    --cc=syzbot+e1c69cadec0f1a078e3d@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.