From: Artem Bityutskiy <dedekind1@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
Brian Norris <computersforpeace@gmail.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] UBIFS: add missing znode freeing in tcn_insert()
Date: Tue, 11 Mar 2014 09:55:40 +0200 [thread overview]
Message-ID: <1394524540.2399.3.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <CAGVrzcZzt+Jii5D8zNTECn92L2-ASoxd4Bcz5WvSNq3rsd754g@mail.gmail.com>
On Mon, 2014-03-10 at 11:44 -0700, Florian Fainelli wrote:
> 2014-03-08 2:46 GMT-08:00 Richard Weinberger <richard.weinberger@gmail.com>:
> > On Sat, Mar 8, 2014 at 1:11 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> >> In case the zi allocation fails in the do_split label, we will fail
> >> freeing zn that we allocated before, add a missing kfree.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >> fs/ubifs/tnc.c | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/fs/ubifs/tnc.c b/fs/ubifs/tnc.c
> >> index 9083bc7ed4ae..9b84d91ea530 100644
> >> --- a/fs/ubifs/tnc.c
> >> +++ b/fs/ubifs/tnc.c
> >> @@ -2105,8 +2105,10 @@ do_split:
> >> dbg_tnc("creating new zroot at level %d", znode->level + 1);
> >>
> >> zi = kzalloc(c->max_znode_sz, GFP_NOFS);
> >> - if (!zi)
> >> + if (!zi) {
> >> + kfree(zn);
> >> return -ENOMEM;
> >> + }
> >>
> >
> > I'm not sure whether this is correct.
> >
> > Around line 2050 we have:
> > ... else {
> > /* Insert into new znode */
> > zi = zn; <---------
> > n -= keep;
> > /* Re-parent */
> > if (zn->level != 0)
> > zbr->znode->parent = zn;
> > }
> >
> > And later:
> > insert_zbranch(zi, zbr, n);
> >
> > By freeing zn you may introduce a use after free bug.
>
> Yes, you are right, I cannot find a good way to make sure this is not
> the case,
I think you do not need to free it. It was allocated and inserted to
TNC. TNC is a global data structure. It gets destroyed (all elements get
freed) when the FS is unmounted. Or if mount fails, it gets freed on the
error path.
So no need to worry about that element.
> variables re-use in this function makes it particularly hard
> to read BTW.
Yes, it could be better, I guess. But this kind of "algorithmic" code is
rarely very readable, it is just not very easy. More comments could help
too.
--
Best Regards,
Artem Bityutskiy
prev parent reply other threads:[~2014-03-11 7:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-08 0:11 [PATCH] UBIFS: add missing znode freeing in tcn_insert() Florian Fainelli
2014-03-08 10:46 ` Richard Weinberger
2014-03-10 18:44 ` Florian Fainelli
2014-03-11 7:55 ` Artem Bityutskiy [this message]
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=1394524540.2399.3.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=f.fainelli@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.weinberger@gmail.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.