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: 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).