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>
next prev parent reply other threads:[~2011-05-19 22:19 UTC|newest]
Thread overview: 14+ 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 12:02 ` James Bottomley
2011-05-20 14:33 ` Christoph Lameter
2011-05-20 14:33 ` Christoph Lameter
2011-05-20 14:42 ` Christoph Lameter
2011-05-20 14:42 ` Christoph Lameter
2011-05-20 18:02 ` J Freyensee
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 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.