linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
To: Li Yang <leoyang.li@nxp.com>
Cc: Kees Cook <keescook@chromium.org>,
	Qiang Zhao <qiang.zhao@nxp.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>
Subject: Re: [PATCH] soc: fsl: qe: Replace one-element array and use struct_size() helper
Date: Wed, 20 May 2020 19:01:52 -0500	[thread overview]
Message-ID: <20200521000152.GC14138@embeddedor> (raw)
In-Reply-To: <CADRPPNR-Croux9FgnrQJJmdF2jNnuAmC+2xMJSgSbkbRv9u8Mw@mail.gmail.com>

On Wed, May 20, 2020 at 06:52:21PM -0500, Li Yang wrote:
> On Mon, May 18, 2020 at 5:57 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Mon, May 18, 2020 at 05:19:04PM -0500, Gustavo A. R. Silva wrote:
> > > The current codebase makes use of one-element arrays in the following
> > > form:
> > >
> > > struct something {
> > >     int length;
> > >     u8 data[1];
> > > };
> > >
> > > struct something *instance;
> > >
> > > instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
> > > instance->length = size;
> > > memcpy(instance->data, source, size);
> > >
> > > but the preferred mechanism to declare variable-length types such as
> > > these ones is a flexible array member[1][2], introduced in C99:
> > >
> > > struct foo {
> > >         int stuff;
> > >         struct boo array[];
> > > };
> > >
> > > By making use of the mechanism above, we will get a compiler warning
> > > in case the flexible array does not occur last in the structure, which
> > > will help us prevent some kind of undefined behavior bugs from being
> > > inadvertently introduced[3] to the codebase from now on. So, replace
> > > the one-element array with a flexible-array member.
> > >
> > > Also, make use of the new struct_size() helper to properly calculate the
> > > size of struct qe_firmware.
> > >
> > > This issue was found with the help of Coccinelle and, audited and fixed
> > > _manually_.
> > >
> > > [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> > > [2] https://github.com/KSPP/linux/issues/21
> > > [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
> > >
> > > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > > ---
> > >  drivers/soc/fsl/qe/qe.c | 4 ++--
> > >  include/soc/fsl/qe/qe.h | 2 +-
> > >  2 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
> > > index 447146861c2c1..2df20d6f85fa4 100644
> > > --- a/drivers/soc/fsl/qe/qe.c
> > > +++ b/drivers/soc/fsl/qe/qe.c
> > > @@ -448,7 +448,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
> > >       unsigned int i;
> > >       unsigned int j;
> > >       u32 crc;
> > > -     size_t calc_size = sizeof(struct qe_firmware);
> > > +     size_t calc_size;
> > >       size_t length;
> > >       const struct qe_header *hdr;
> > >
> > > @@ -480,7 +480,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
> > >       }
> > >
> > >       /* Validate the length and check if there's a CRC */
> > > -     calc_size += (firmware->count - 1) * sizeof(struct qe_microcode);
> > > +     calc_size = struct_size(firmware, microcode, firmware->count);
> > >
> > >       for (i = 0; i < firmware->count; i++)
> > >               /*
> > > diff --git a/include/soc/fsl/qe/qe.h b/include/soc/fsl/qe/qe.h
> > > index e282ac01ec081..3feddfec9f87d 100644
> > > --- a/include/soc/fsl/qe/qe.h
> > > +++ b/include/soc/fsl/qe/qe.h
> > > @@ -307,7 +307,7 @@ struct qe_firmware {
> > >               u8 revision;            /* The microcode version revision */
> > >               u8 padding;             /* Reserved, for alignment */
> > >               u8 reserved[4];         /* Reserved, for future expansion */
> > > -     } __attribute__ ((packed)) microcode[1];
> > > +     } __packed microcode[];
> > >       /* All microcode binaries should be located here */
> > >       /* CRC32 should be located here, after the microcode binaries */
> > >  } __attribute__ ((packed));
> > > --
> > > 2.26.2
> > >
> >
> > Hm, looking at this code, I see a few other things that need to be
> > fixed:
> >
> > 1) drivers/tty/serial/ucc_uart.c does not do a be32_to_cpu() conversion
> >    on the length test (understandably, a little-endian system has never run
> >    this code since it's ppc specific), but it's still wrong:
> >
> >         if (firmware->header.length != fw->size) {
> >
> >    compare to the firmware loader:
> >
> >         length = be32_to_cpu(hdr->length);
> >
> > 2) drivers/soc/fsl/qe/qe.c does not perform bounds checking on the
> >    per-microcode offsets, so the uploader might send data outside the
> >    firmware buffer. Perhaps:
> 
> We do validate the CRC for each microcode, it is unlikely the CRC
> check can pass if the offset or length is not correct.  But you are
> probably right that it will be safer to check the boundary and fail
> quicker before we actually start the CRC check.  Will you come up with
> a formal patch or you want us to deal with it?
> 

Li,

I will send a proper patch for this.

Thanks
--
Gustavo

> >
> >
> > diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
> > index 447146861c2c..c4e0bc452f03 100644
> > --- a/drivers/soc/fsl/qe/qe.c
> > +++ b/drivers/soc/fsl/qe/qe.c
> > @@ -451,6 +451,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
> >         size_t calc_size = sizeof(struct qe_firmware);
> >         size_t length;
> >         const struct qe_header *hdr;
> > +       void *firmware_end;
> >
> >         if (!firmware) {
> >                 printk(KERN_ERR "qe-firmware: invalid pointer\n");
> > @@ -491,19 +492,39 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
> >                 calc_size += sizeof(__be32) *
> >                         be32_to_cpu(firmware->microcode[i].count);
> >
> > -       /* Validate the length */
> > +       /* Validate total length */
> >         if (length != calc_size + sizeof(__be32)) {
> >                 printk(KERN_ERR "qe-firmware: invalid length\n");
> >                 return -EPERM;
> >         }
> >
> >         /* Validate the CRC */
> > -       crc = be32_to_cpu(*(__be32 *)((void *)firmware + calc_size));
> > +       firmware_end = (void *)firmware + calc_size;
> > +       crc = be32_to_cpu(*(__be32 *)firmware_end);
> >         if (crc != crc32(0, firmware, calc_size)) {
> >                 printk(KERN_ERR "qe-firmware: firmware CRC is invalid\n");
> >                 return -EIO;
> >         }
> >
> > +       /* Validate ucode lengths and offsets */
> > +       for (i = 0; i < firmware->count; i++) {
> > +               const struct qe_microcode *ucode = &firmware->microcode[i];
> > +               __be32 *code;
> > +               size_t count;
> > +
> > +               if (!ucode->code_offset)
> > +                       continue;
> > +
> > +               code = (void *)firmware + be32_to_cpu(ucode->code_offset);
> > +               count = be32_to_cpu(ucode->count) * sizeof(*code);
> > +
> > +               if (code < firmware || code >= firmware_end ||
> > +                   code + count < firmware || code + count >= firmware_end) {
> > +                       printk(KERN_ERR "qe-firmware: invalid ucode offset\n");
> > +                       return -EIO;
> > +               }
> > +       }
> > +
> >         /*
> >          * If the microcode calls for it, split the I-RAM.
> >          */
> >
> >
> > I haven't tested this.
> >
> >
> > --
> > Kees Cook

  reply	other threads:[~2020-05-20 23:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-18 22:19 [PATCH] soc: fsl: qe: Replace one-element array and use struct_size() helper Gustavo A. R. Silva
2020-05-18 22:56 ` Kees Cook
2020-05-20 23:52   ` Li Yang
2020-05-21  0:01     ` Gustavo A. R. Silva [this message]
2020-05-21  3:24     ` Kees Cook
2020-05-22 21:21       ` Li Yang
2020-05-25  2:47         ` Qiang Zhao
2020-05-26 19:56           ` Li Yang
2020-05-19  3:37 ` Qiang Zhao
2020-05-22 21:23 ` Li Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200521000152.GC14138@embeddedor \
    --to=gustavoars@kernel.org \
    --cc=gustavo@embeddedor.com \
    --cc=keescook@chromium.org \
    --cc=leoyang.li@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=qiang.zhao@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).