linux-kernel - Re: possible krealloc with __GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1470410753.28648.2.camel@perches.com>
Date:	Fri, 05 Aug 2016 08:25:53 -0700
From:	Joe Perches <joe@...ches.com>
To:	Matt Fleming <matt@...eblueprint.co.uk>
Cc:	Chris Metcalf <cmetcalf@...era.com>, Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ferruh Yigit <fery@...ress.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: possible krealloc with __GFP_ZERO defects

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.