Re: possible krealloc with __GFP_ZERO defects

[Joe Perches <joe@perches.com>]

On Fri, 2016-08-05 at 12:37 +0100, Matt Fleming wrote:
> On Thu, 28 Jul, at 11:11:31AM, Joe Perches wrote:
> > 
> > (forwarding to the maintainers of other uses)
> > 
> > On Thu, 2016-07-28 at 10:27 -0700, Joe Perches wrote:
> > > 
> > > There is a defect in krealloc with __GFP_ZERO so this code in
> > > drivers/chat/tile-srom.c may not work properly:
> > > 
> > > drivers/char/tile-srom.c-       for (i = 0; ; i++) {
> > > drivers/char/tile-srom.c-               int devhdl;
> > > drivers/char/tile-srom.c-               char buf[20];
> > > drivers/char/tile-srom.c-               struct srom_dev *new_srom_devices =
> > > drivers/char/tile-srom.c-                       krealloc(srom_devices, (i+1) * sizeof(struct srom_dev),
> > > drivers/char/tile-srom.c:                                GFP_KERNEL | __GFP_ZERO);
> > > drivers/char/tile-srom.c-               if (!new_srom_devices) {
> > > drivers/char/tile-srom.c-                       result = -ENOMEM;
> > > drivers/char/tile-srom.c-                       goto fail_mem;
> > > drivers/char/tile-srom.c-               }
> > > drivers/char/tile-srom.c-               srom_devices = new_srom_devices;
> > > 
> > > http://linux-kernel.vger.kernel.narkive.com/xyiQV3vf/slab-krealloc-with-gfp-zero-defect
> > Here are the other in-tree uses that may not work properly
> > 
> > $ grep-2.5.4 -rP --include=*.[ch] -n "krealloc[^;]+__GFP_ZERO" *
> > drivers/firmware/efi/capsule-loader.c:87:	temp_page = krealloc(cap_info->pages,
> > 			     pages_needed * sizeof(void *),
> > 			     GFP_KERNEL | __GFP_ZERO);
> > drivers/char/tile-srom.c:375:			krealloc(srom_devices, (i+1) * sizeof(struct srom_dev),
> > 				 GFP_KERNEL | __GFP_ZERO);
> > drivers/input/touchscreen/cyttsp4_core.c:521:		p = krealloc(si->btn, si->si_ofs.btn_keys_size,
> > 				GFP_KERNEL|__GFP_ZERO);
> > drivers/input/touchscreen/cyttsp4_core.c:565:	p = krealloc(si->xy_mode, si->si_ofs.mode_size, GFP_KERNEL|__GFP_ZERO);
> > drivers/input/touchscreen/cyttsp4_core.c:570:	p = krealloc(si->xy_data, si->si_ofs.data_size, GFP_KERNEL|__GFP_ZERO);
> > drivers/input/touchscreen/cyttsp4_core.c:575:	p = krealloc(si->btn_rec_data,
> > 			si->si_ofs.btn_rec_size * si->si_ofs.num_btns,
> > 			GFP_KERNEL|__GFP_ZERO);
> > sound/hda/array.c:28:		nlist = krealloc(array->list, size, GFP_KERNEL | __GFP_ZERO);
> > sound/core/info.c:342:		char *nbuf = krealloc(buf->buffer, PAGE_ALIGN(next),
> > 				      GFP_KERNEL | __GFP_ZERO);
> Isn't this a bug in krealloc()?

Yes.  Reported 3+ years ago.

http://linux-kernel.vger.kernel.narkive.com/xyiQV3vf/slab-krealloc-with-gfp-zero-defect

This sequence can return non-zeroed memory from the
padding area of the original allocation.

ptr = kzalloc(foo, GFP_KERNEL);
if (!ptr)
...
new_ptr = krealloc(ptr, foo + bar, GFP_KERNEL | __GFP_ZERO);

If the realloc size is within the first actual allocation
then the additional memory is not zeroed.

If the realloc size is not within the original allocation
size, any non-zeroed padding from the original allocation
is overwriting newly allocated zeroed memory.

Maybe someone more familiar with the alignment & padding can
add the proper memset(,0,) for the __GFP_ZERO cases and also
optimize kmalloc_track_caller to not use __GFP_ZERO, memcpy
the current (non padded) size and zero the newly returned
remainder if necessary.