Am 15.12.20 um 04:03 schrieb Andrew Morton:
From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> Subject: mm: slab: clarify krealloc()'s behavior with __GFP_ZERO Patch series "slab: provide and use krealloc_array()", v3. Andy brought to my attention the fact that users allocating an array of equally sized elements should check if the size multiplication doesn't overflow. This is why we have helpers like kmalloc_array(). However we don't have krealloc_array() equivalent and there are many users who do their own multiplication when calling krealloc() for arrays. This series provides krealloc_array() and uses it in a couple places. A separate series will follow adding devm_krealloc_array() which is needed in the xilinx adc driver. This patch (of 9): __GFP_ZERO is ignored by krealloc() (unless we fall-back to kmalloc() path, in which case it's honored). Point that out in the kerneldoc. Link: https://lkml.kernel.org/r/20201109110654.12547-1-brgl@xxxxxxxx Link: https://lkml.kernel.org/r/20201109110654.12547-2-brgl@xxxxxxxx Signed-off-by: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> Cc: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Cc: Sumit Semwal <sumit.semwal@xxxxxxxxxx> Cc: Gustavo Padovan <gustavo@xxxxxxxxxxx> Cc: Christian Knig <christian.koenig@xxxxxxx> Cc: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> Cc: Borislav Petkov <bp@xxxxxxxxx> Cc: Tony Luck <tony.luck@xxxxxxxxx> Cc: James Morse <james.morse@xxxxxxx> Cc: Robert Richter <rric@xxxxxxxxxx> Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> Cc: Maxime Ripard <mripard@xxxxxxxxxx> Cc: Thomas Zimmermann <tzimmermann@xxxxxxx> Cc: David Airlie <airlied@xxxxxxxx> Cc: Daniel Vetter <daniel@xxxxxxxx> Cc: Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> Cc: "Michael S . Tsirkin" <mst@xxxxxxxxxx> Cc: Jason Wang <jasowang@xxxxxxxxxx> Cc: Christoph Lameter <cl@xxxxxxxxx> Cc: Pekka Enberg <penberg@xxxxxxxxxx> Cc: David Rientjes <rientjes@xxxxxxxxxx> Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> Cc: Jaroslav Kysela <perex@xxxxxxxx> Cc: Takashi Iwai <tiwai@xxxxxxxx> Cc: Borislav Petkov <bp@xxxxxxx> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> Cc: Takashi Iwai <tiwai@xxxxxxx> Cc: Vlastimil Babka <vbabka@xxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- mm/slab_common.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/mm/slab_common.c~mm-slab-clarify-kreallocs-behavior-with-__gfp_zero +++ a/mm/slab_common.c @@ -1091,9 +1091,9 @@ static __always_inline void *__do_kreall * @flags: the type of memory to allocate. * * The contents of the object pointed to are preserved up to the - * lesser of the new and old sizes. If @p is %NULL, krealloc() - * behaves exactly like kmalloc(). If @new_size is 0 and @p is not a - * %NULL pointer, the object pointed to is freed. + * lesser of the new and old sizes (__GFP_ZERO flag is effectively ignored). + * If @p is %NULL, krealloc() behaves exactly like kmalloc(). If @new_size + * is 0 and @p is not a %NULL pointer, the object pointed to is freed.
Question: Can the fact that __GFP_ZERO is effectively ignored cause an information leak if new size is larger than old size and the array is somehow copied to user space?
I think the answer is no, but just wanted to double check. Maybe we should note that here.
Thanks, Christian.
* * Return: pointer to the allocated memory or %NULL in case of error */ _
