linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: J Freyensee <james_p_freyensee@linux.intel.com>
To: Christoph Lameter <cl@linux.com>
Cc: linux-mm@kvack.org, gregkh@suse.de, hari.k.kanigeri@intel.com
Subject: Re: [PATCH] kernel buffer overflow kmalloc_slab() fix
Date: Thu, 19 May 2011 15:19:12 -0700	[thread overview]
Message-ID: <1305843552.2400.36.camel@localhost> (raw)
In-Reply-To: <alpine.DEB.2.00.1105191618460.12530@router.home>

On Thu, 2011-05-19 at 16:24 -0500, Christoph Lameter wrote:
> On Thu, 19 May 2011, J Freyensee wrote:
> 
> > On Thu, 2011-05-19 at 15:51 -0500, Christoph Lameter wrote:
> > > On Thu, 19 May 2011, james_p_freyensee@linux.intel.com wrote:
> > >
> > > > From: J Freyensee <james_p_freyensee@linux.intel.com>
> > > >
> > > > Currently, kmalloc_index() can return -1, which can be
> > > > passed right to the kmalloc_caches[] array, cause a
> > >
> > > No kmalloc_index() cannot return -1 for the use case that you are
> > > considering here. The value passed as a size to
> > > kmalloc_slab is bounded by 2 * PAGE_SIZE and kmalloc_slab will only return
> > > -1 for sizes > 4M. So we will have to get machines with page sizes > 2M
> > > before this can be triggered.
> > >
> > >
> >
> > Okay.  I thought it would still be good to check for -1 anyways, even if
> > machines today cannot go above 2M page sizes.  I would think it would be
> > better for software code to always make sure a case that this could
> > never happen instead of relying on whatever physical hardware limits the
> > linux kernel could be running on on today's machines or future machines,
> > because technology has shown limits can change.  I would think
> > regardless what this code runs on, this is still a software flaw that
> > can be considered not a good thing to allow lying around in software
> > code that can easily be fixed.
> 
> This is basically macro style code that is mostly folded at compile time
> and we have to obey certain restrictions to convince the compiler to
> properly do that. Took us a long time to get that right.
> 
> Not sure what to do instead of returning -1 in kmalloc_slab. 

I think returning -1 is fine; I just think code using the function
should be checking for it and protect itself for errors in kernel space.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-05-19 22:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-19 19:51 [PATCH] kernel buffer overflow kmalloc_slab() fix james_p_freyensee
2011-05-19 20:51 ` Christoph Lameter
2011-05-19 21:14   ` J Freyensee
2011-05-19 21:24     ` Christoph Lameter
2011-05-19 22:19       ` J Freyensee [this message]
2011-05-20 14:32         ` Christoph Lameter
2011-05-20 12:02   ` James Bottomley
2011-05-20 14:33     ` Christoph Lameter
2011-05-20 14:42       ` Christoph Lameter
2011-05-20 18:02         ` J Freyensee

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=1305843552.2400.36.camel@localhost \
    --to=james_p_freyensee@linux.intel.com \
    --cc=cl@linux.com \
    --cc=gregkh@suse.de \
    --cc=hari.k.kanigeri@intel.com \
    --cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).