All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Xiaoming Ni <nixiaoming@huawei.com>
Cc: bbrezillon@kernel.org, richard@nod.at, dilinger@queued.net,
	linux-kernel@vger.kernel.org, daniel.santos@pobox.com,
	linux-mtd@lists.infradead.org, houtao1@huawei.com,
	dwmw2@infradead.org
Subject: Re: [PATCH] jffs2:freely allocate memory when parameters are invalid
Date: Fri, 20 Sep 2019 13:45:32 +0100	[thread overview]
Message-ID: <20190920124532.GN1131@ZenIV.linux.org.uk> (raw)
In-Reply-To: <206f8d57-dad9-26c3-6bf6-1d000f5698d4@huawei.com>

On Fri, Sep 20, 2019 at 08:21:53PM +0800, Xiaoming Ni wrote:
> 
> 
> On 2019/9/20 19:43, Al Viro wrote:
> > On Fri, Sep 20, 2019 at 02:54:38PM +0800, Xiaoming Ni wrote:
> >> Use kzalloc() to allocate memory in jffs2_fill_super().
> >> Freeing memory when jffs2_parse_options() fails will cause
> >> use-after-free and double-free in jffs2_kill_sb()
> > 
> > ... so we are not freeing it there.  What's the problem?
> 
> No code logic issues, no memory leaks
> 
> But there is too much code logic between memory allocation and free,
> which is difficult to understand.

Er?  An instance of jffs2 superblock might have a related object
attached to it; it is created in jffs2 superblock constructor and
freed in destructor.

> The modified code is easier to understand.

You are making the cleanup logics harder to follow.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: Xiaoming Ni <nixiaoming@huawei.com>
Cc: dwmw2@infradead.org, dilinger@queued.net, richard@nod.at,
	houtao1@huawei.com, bbrezillon@kernel.org,
	daniel.santos@pobox.com, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] jffs2:freely allocate memory when parameters are invalid
Date: Fri, 20 Sep 2019 13:45:32 +0100	[thread overview]
Message-ID: <20190920124532.GN1131@ZenIV.linux.org.uk> (raw)
In-Reply-To: <206f8d57-dad9-26c3-6bf6-1d000f5698d4@huawei.com>

On Fri, Sep 20, 2019 at 08:21:53PM +0800, Xiaoming Ni wrote:
> 
> 
> On 2019/9/20 19:43, Al Viro wrote:
> > On Fri, Sep 20, 2019 at 02:54:38PM +0800, Xiaoming Ni wrote:
> >> Use kzalloc() to allocate memory in jffs2_fill_super().
> >> Freeing memory when jffs2_parse_options() fails will cause
> >> use-after-free and double-free in jffs2_kill_sb()
> > 
> > ... so we are not freeing it there.  What's the problem?
> 
> No code logic issues, no memory leaks
> 
> But there is too much code logic between memory allocation and free,
> which is difficult to understand.

Er?  An instance of jffs2 superblock might have a related object
attached to it; it is created in jffs2 superblock constructor and
freed in destructor.

> The modified code is easier to understand.

You are making the cleanup logics harder to follow.

  reply	other threads:[~2019-09-20 12:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-20  6:54 [PATCH] jffs2:freely allocate memory when parameters are invalid Xiaoming Ni
2019-09-20  6:54 ` Xiaoming Ni
2019-09-20 11:43 ` Al Viro
2019-09-20 11:43   ` Al Viro
2019-09-20 12:21   ` Xiaoming Ni
2019-09-20 12:21     ` Xiaoming Ni
2019-09-20 12:45     ` Al Viro [this message]
2019-09-20 12:45       ` Al Viro
2019-09-20 12:54       ` Al Viro
2019-09-20 12:54         ` Al Viro
2019-09-20 14:13         ` Xiaoming Ni
2019-09-20 14:13           ` Xiaoming Ni
2019-09-20 14:38           ` Richard Weinberger
2019-09-20 14:38             ` Richard Weinberger
2019-09-21  1:24             ` Hou Tao
2019-09-21  1:24               ` Hou Tao
2019-09-21 15:37               ` Richard Weinberger
2019-09-21 15:37                 ` Richard Weinberger
2019-09-20 15:28           ` Al Viro
2019-09-20 15:28             ` 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=20190920124532.GN1131@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=bbrezillon@kernel.org \
    --cc=daniel.santos@pobox.com \
    --cc=dilinger@queued.net \
    --cc=dwmw2@infradead.org \
    --cc=houtao1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nixiaoming@huawei.com \
    --cc=richard@nod.at \
    /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.