Re: [PATCH] mtd: nftl: Remove VLA usage

[Boris Brezillon <boris.brezillon@bootlin.com>]

On Sun, 29 Apr 2018 07:31:15 -0700
Kees Cook <keescook@chromium.org> wrote:

> On Sun, Apr 29, 2018 at 2:16 AM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > Hi Kees,
> >
> > On Mon, 23 Apr 2018 13:35:00 -0700
> > Kees Cook <keescook@chromium.org> wrote:
> >  
> >> On the quest to remove all VLAs from the kernel[1] this changes the
> >> check_free_sectors() routine to use the same stack buffer for both
> >> data byte checks (SECTORSIZE) and oob byte checks (oobsize). Since
> >> these regions aren't needed at the same time, they don't need to be
> >> consecutively allocated. Additionally, while it's possible for oobsize
> >> to be large, it is unlikely to be larger than the actual SECTORSIZE. As
> >> such, remove the VLA, adjust offsets and add a sanity check to make sure
> >> we never get a pathological oobsize.
> >>
> >> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
> >>
> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >> ---
> >>  drivers/mtd/inftlmount.c | 11 ++++++++---
> >>  drivers/mtd/nftlmount.c  | 11 ++++++++---
> >>  2 files changed, 16 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/mtd/inftlmount.c b/drivers/mtd/inftlmount.c
> >> index aab4f68bd36f..9cdae7f0fc2e 100644
> >> --- a/drivers/mtd/inftlmount.c
> >> +++ b/drivers/mtd/inftlmount.c
> >> @@ -334,7 +334,7 @@ static int memcmpb(void *a, int c, int n)
> >>  static int check_free_sectors(struct INFTLrecord *inftl, unsigned int address,
> >>       int len, int check_oob)
> >>  {
> >> -     u8 buf[SECTORSIZE + inftl->mbd.mtd->oobsize];
> >> +     u8 buf[SECTORSIZE];  
> >
> > Could we instead move to dynamic allocation. I mean, SECTORSIZE is 512
> > bytes, so only with this function we consume 1/16 of the stack. Not to
> > mention that some MTD drivers might want to do DMA on buffer passed by
> > the MTD user, and if the buffer is on the stack they'll have to use a
> > bounce buffer instead.  
> 
> Sure! I can rework it to do that. Is GFP_KERNEL okay for that, or does
> it need something else?

Just had a quick look, and I think GFP_KERNEL is good.