Re: [PATCH] kernel buffer overflow kmalloc_slab() fix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx wrote:
> > >
> > > > From: J Freyensee <james_p_freyensee@xxxxxxxxxxxxxxx>
> > > >
> > > > 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@xxxxxxxxxx  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@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]