linux-kernel - Re: [PATCH v2][next] scsi: mpt3sas: Replace one-element array with flexible-array in struct _MPI2_CONFIG_PAGE_IO_UNIT

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <202103101058.16ED27BE3@keescook>
Date:   Wed, 10 Mar 2021 11:07:21 -0800
From:   Kees Cook <keescook@...omium.org>
To:     "Gustavo A. R. Silva" <gustavoars@...nel.org>
Cc:     James Bottomley <jejb@...ux.ibm.com>,
        Sathya Prakash <sathya.prakash@...adcom.com>,
        Sreekanth Reddy <sreekanth.reddy@...adcom.com>,
        Suganath Prabu Subramani 
        <suganath-prabu.subramani@...adcom.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        MPT-FusionLinux.pdl@...adcom.com, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2][next] scsi: mpt3sas: Replace one-element array with
 flexible-array in struct _MPI2_CONFIG_PAGE_IO_UNIT_3

On Mon, Mar 08, 2021 at 02:41:29PM -0600, Gustavo A. R. Silva wrote:
> On Mon, Mar 08, 2021 at 12:12:59PM -0800, James Bottomley wrote:
> > On Mon, 2021-03-08 at 13:32 -0600, Gustavo A. R. Silva wrote:
> > > Hi all,
> > > 
> > > Friendly ping: who can review/take this, please?
> > 
> > Well, before embarking on a huge dynamic update, let's ask Broadcom the
> > simpler question of why isn't MPI2_IO_UNIT_PAGE_3_GPIO_VAL_MAX simply
> > set to 36?  There's no dynamic allocation of anything in the current
> > code ... it's all hard coded to allocate 36 entries.  If there's no
> > need for anything dynamic then the kzalloc could become 
> 
> Yeah; and if that is the case, then there is no even need for kzalloc()
> at all, and it can be replaced by memset():
> 
> diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> index 43a3bf8ff428..d00431f553e1 100644
> --- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> +++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> @@ -992,7 +992,7 @@ typedef struct _MPI2_CONFIG_PAGE_IO_UNIT_1 {
>   *one and check the value returned for GPIOCount at runtime.
>   */
>  #ifndef MPI2_IO_UNIT_PAGE_3_GPIO_VAL_MAX
> -#define MPI2_IO_UNIT_PAGE_3_GPIO_VAL_MAX    (1)
> +#define MPI2_IO_UNIT_PAGE_3_GPIO_VAL_MAX    (36)
>  #endif
> 
>  typedef struct _MPI2_CONFIG_PAGE_IO_UNIT_3 {
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> index 44f9a05db94e..23fcf29bfd67 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> @@ -3203,7 +3203,7 @@ BRM_status_show(struct device *cdev, struct device_attribute *attr,
>  {
>         struct Scsi_Host *shost = class_to_shost(cdev);
>         struct MPT3SAS_ADAPTER *ioc = shost_priv(shost);
> -       Mpi2IOUnitPage3_t *io_unit_pg3 = NULL;
> +       Mpi2IOUnitPage3_t io_unit_pg3;
>         Mpi2ConfigReply_t mpi_reply;
>         u16 backup_rail_monitor_status = 0;
>         u16 ioc_status;
> @@ -3221,16 +3221,10 @@ BRM_status_show(struct device *cdev, struct device_attribute *attr,
>                 goto out;
> 
>         /* allocate upto GPIOVal 36 entries */
> -       sz = offsetof(Mpi2IOUnitPage3_t, GPIOVal) + (sizeof(u16) * 36);
> -       io_unit_pg3 = kzalloc(sz, GFP_KERNEL);
> -       if (!io_unit_pg3) {
> -               rc = -ENOMEM;
> -               ioc_err(ioc, "%s: failed allocating memory for iounit_pg3: (%d) bytes\n",
> -                       __func__, sz);
> -               goto out;
> -       }
> +       sz = sizeof(io_unit_pg3);
> +       memset(&io_unit_pg3, 0, sz);

I like this a lot. It makes the code way simpler.

Putting this on the stack makes it faster, and it's less than 100 bytes,
which seems entirely reasonable.

> 
> -       if (mpt3sas_config_get_iounit_pg3(ioc, &mpi_reply, io_unit_pg3, sz) !=
> +       if (mpt3sas_config_get_iounit_pg3(ioc, &mpi_reply, &io_unit_pg3, sz) !=

The only thing I can imagine is if this ends up doing DMA, which isn't
allowed on the stack. However, in looking down through the call path,
it's _copied_ into DMA memory, so this appears entirely safe.
 
Can you send this as a "normal" patch? Feel free to include:

Reviewed-by: Kees Cook <keescook@...omium.org>

Thanks!

-Kees

>             0) {
>                 ioc_err(ioc, "%s: failed reading iounit_pg3\n",
>                         __func__);
> @@ -3246,19 +3240,18 @@ BRM_status_show(struct device *cdev, struct device_attribute *attr,
>                 goto out;
>         }
> 
> -       if (io_unit_pg3->GPIOCount < 25) {
> -               ioc_err(ioc, "%s: iounit_pg3->GPIOCount less than 25 entries, detected (%d) entries\n",
> -                       __func__, io_unit_pg3->GPIOCount);
> +       if (io_unit_pg3.GPIOCount < 25) {
> +               ioc_err(ioc, "%s: iounit_pg3.GPIOCount less than 25 entries, detected (%d) entries\n",
> +                       __func__, io_unit_pg3.GPIOCount);
>                 rc = -EINVAL;
>                 goto out;
>         }
> 
>         /* BRM status is in bit zero of GPIOVal[24] */
> -       backup_rail_monitor_status = le16_to_cpu(io_unit_pg3->GPIOVal[24]);
> +       backup_rail_monitor_status = le16_to_cpu(io_unit_pg3.GPIOVal[24]);
>         rc = snprintf(buf, PAGE_SIZE, "%d\n", (backup_rail_monitor_status & 1));
> 
>   out:
> -       kfree(io_unit_pg3);
>         mutex_unlock(&ioc->pci_access_mutex);
>         return rc;
>  }
> 
> > 
> > 	io_unit_pg3 = kzalloc(sizeof(*io_unit_pg3), GFP_KERNEL);
> >
> 
> Thanks
> --
> Gustavo

-- 
Kees Cook