From: Ralf Baechle <ralf@linux-mips.org>
To: Jesper Juhl <jj@chaosbits.net>
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Check vmalloc return value in vpe_open
Date: Sun, 7 Nov 2010 14:29:33 +0000 [thread overview]
Message-ID: <20101107142933.GA7999@linux-mips.org> (raw)
In-Reply-To: <alpine.LNX.2.00.1010301823350.1572@swampdragon.chaosbits.net>
On Sat, Oct 30, 2010 at 06:37:16PM +0200, Jesper Juhl wrote:
> I noticed that the return value of the
> vmalloc() call in arch/mips/kernel/vpe.c::vpe_open() is not checked, so we
> potentially store a null pointer in v->pbuffer. As far as I can tell this
> will be a problem. However, I don't know the mips code at all, so there
> may be something, somewhere where I did not look, that handles this in a
> safe manner but I couldn't find it.
>
> To me it looks like we should do what the patch below implements and check
> for a null return and then return -ENOMEM in that case. Comments?
All users check if the buffer was successfully allocated so the code is
safe wrt. to that.
Doesn't mean that it's not a pukeogenic piece of code. Look at the use of
v->pbuffer in vpe_release for example. First use it the vmalloc'ed memory
then carefully check the pointer for being non-NULL before calling vfree.
If the pointer could actually be non-NULL that's too late and vfree does
that check itself anyway. And more such gems, general uglyness and
freedom of concept. It used to be even worse.
Ralf
next prev parent reply other threads:[~2010-11-07 14:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-30 16:37 [PATCH] Check vmalloc return value in vpe_open Jesper Juhl
2010-11-07 14:29 ` Ralf Baechle [this message]
2010-11-07 18:48 ` [PATCH] MIPS VPE support module: don't deref potentially null pbuffer and don't do pointless null check before vfree Jesper Juhl
2010-11-08 22:44 ` Ralf Baechle
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=20101107142933.GA7999@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=jj@chaosbits.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
/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