mhi.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* [PATCH 00/26] use array_size
@ 2023-06-23 21:14 Julia Lawall
  2023-06-23 21:14 ` [PATCH 10/26] bus: mhi: host: " Julia Lawall
  0 siblings, 1 reply; 9+ messages in thread
From: Julia Lawall @ 2023-06-23 21:14 UTC (permalink / raw)
  To: linux-staging
  Cc: keescook, kernel-janitors, Tianshu Qiu, Bingbu Cao, linux-sgx,
	H. Peter Anvin, Dave Hansen, kasan-dev, Andrey Konovalov,
	Dmitry Vyukov, iommu, linux-tegra, Robin Murphy, Krishna Reddy,
	linux-scsi, linux-rdma, dri-devel, linux-kernel, netdev,
	Shailend Chand, Benjamin Gaignard, Liam Mark, Laura Abbott,
	Brian Starkey, John Stultz, linux-media, linaro-mm-sig,
	Xuan Zhuo, virtualization, mhi, linux-arm-msm, linux-btrfs,
	intel-gvt-dev, intel-gfx, VMware Graphics Reviewers,
	linux-hyperv

Use array_size to protect against multiplication overflows.

This follows up on the following patches by Kees Cook from 2018.

42bc47b35320 ("treewide: Use array_size() in vmalloc()")
fad953ce0b22 ("treewide: Use array_size() in vzalloc()")

The changes were done using the following Coccinelle semantic patch,
adapted from the one posted by Kees.

// Drop single-byte sizes and redundant parens.
@@
    expression COUNT;
    typedef u8;
    typedef __u8;
    type t = {u8,__u8,char,unsigned char};
    identifier alloc = {vmalloc,vzalloc};
@@
      alloc(
-           (sizeof(t)) * (COUNT)
+           COUNT
      , ...)

// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
    expression COUNT;
    size_t e1, e2, e3;
    identifier alloc = {vmalloc,vzalloc};
@@

(    
      alloc(
-           (e1) * (e2) * (e3)
+           array3_size(e1, e2, e3)
      ,...)
|
      alloc(
-           (e1) * (e2) * (COUNT)
+           array3_size(COUNT, e1, e2)
      ,...)
)

// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
    expression STRIDE, COUNT;
    size_t e;
    identifier alloc = {vmalloc,vzalloc};
@@

      alloc(
-           (e) * (COUNT) * (STRIDE)
+           array3_size(COUNT, STRIDE, e)
      ,...)

// Any remaining multi-factor products, first at least 3-factor products
// when they're not all constants...
@@
    expression E1, E2, E3;
    constant C1, C2, C3;
    identifier alloc = {vmalloc,vzalloc};
@@
    
(
      alloc(C1 * C2 * C3,...)
|
      alloc(
-           (E1) * (E2) * (E3)
+           array3_size(E1, E2, E3)
      ,...)
)

// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
    size_t e1,e2;
    expression COUNT;
    identifier alloc = {vmalloc,vzalloc};
@@

(
      alloc(
-           (e1) * (e2)
+           array_size(e1, e2)
      ,...)
|
      alloc(
-           (e1) * (COUNT)
+           array_size(COUNT, e1)
      ,...)
)
    
// And then all remaining 2 factors products when they're not all constants.
@@
    expression E1, E2;
    constant C1, C2;
    identifier alloc = {vmalloc,vzalloc};
@@
    
(
      alloc(C1 * C2,...)
|
      alloc(
-           (E1) * (E2)
+           array_size(E1, E2)
      ,...)
)


---

 arch/x86/kernel/cpu/sgx/main.c                    |    3 ++-
 drivers/accel/habanalabs/common/device.c          |    3 ++-
 drivers/accel/habanalabs/common/state_dump.c      |    6 +++---
 drivers/bus/mhi/host/init.c                       |    4 ++--
 drivers/comedi/comedi_buf.c                       |    4 ++--
 drivers/dma-buf/heaps/system_heap.c               |    2 +-
 drivers/gpu/drm/gud/gud_pipe.c                    |    2 +-
 drivers/gpu/drm/i915/gvt/gtt.c                    |    6 ++++--
 drivers/gpu/drm/vmwgfx/vmwgfx_devcaps.c           |    2 +-
 drivers/infiniband/hw/bnxt_re/qplib_res.c         |    4 ++--
 drivers/infiniband/hw/erdma/erdma_verbs.c         |    4 ++--
 drivers/infiniband/sw/siw/siw_qp.c                |    4 ++--
 drivers/infiniband/sw/siw/siw_verbs.c             |    6 +++---
 drivers/iommu/tegra-gart.c                        |    4 ++--
 drivers/net/ethernet/amd/pds_core/core.c          |    4 ++--
 drivers/net/ethernet/freescale/enetc/enetc.c      |    4 ++--
 drivers/net/ethernet/google/gve/gve_tx.c          |    2 +-
 drivers/net/ethernet/marvell/octeon_ep/octep_rx.c |    2 +-
 drivers/net/ethernet/microsoft/mana/hw_channel.c  |    2 +-
 drivers/net/ethernet/pensando/ionic/ionic_lif.c   |    4 ++--
 drivers/scsi/fnic/fnic_trace.c                    |    2 +-
 drivers/scsi/qla2xxx/qla_init.c                   |    4 ++--
 drivers/staging/media/ipu3/ipu3-mmu.c             |    2 +-
 drivers/vdpa/vdpa_user/iova_domain.c              |    3 +--
 drivers/virtio/virtio_mem.c                       |    6 +++---
 fs/btrfs/zoned.c                                  |    5 +++--
 kernel/kcov.c                                     |    2 +-
 lib/test_vmalloc.c                                |   12 ++++++------
 28 files changed, 56 insertions(+), 52 deletions(-)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 10/26] bus: mhi: host: use array_size
  2023-06-23 21:14 [PATCH 00/26] use array_size Julia Lawall
@ 2023-06-23 21:14 ` Julia Lawall
  2023-06-23 21:30   ` Jeffrey Hugo
  2023-06-26 14:53   ` Jeffrey Hugo
  0 siblings, 2 replies; 9+ messages in thread
From: Julia Lawall @ 2023-06-23 21:14 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: keescook, kernel-janitors, mhi, linux-arm-msm, linux-kernel

Use array_size to protect against multiplication overflows.

The changes were done using the following Coccinelle semantic patch:

// <smpl>
@@
    expression E1, E2;
    constant C1, C2;
    identifier alloc = {vmalloc,vzalloc};
@@
    
(
      alloc(C1 * C2,...)
|
      alloc(
-           (E1) * (E2)
+           array_size(E1, E2)
      ,...)
)
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>

---
 drivers/bus/mhi/host/init.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f72fcb66f408..34a543a67068 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -759,8 +759,8 @@ static int parse_ch_cfg(struct mhi_controller *mhi_cntrl,
 	 * so to avoid any memory possible allocation failures, vzalloc is
 	 * used here
 	 */
-	mhi_cntrl->mhi_chan = vzalloc(mhi_cntrl->max_chan *
-				      sizeof(*mhi_cntrl->mhi_chan));
+	mhi_cntrl->mhi_chan = vzalloc(array_size(mhi_cntrl->max_chan,
+				      sizeof(*mhi_cntrl->mhi_chan)));
 	if (!mhi_cntrl->mhi_chan)
 		return -ENOMEM;
 


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH 10/26] bus: mhi: host: use array_size
  2023-06-23 21:14 ` [PATCH 10/26] bus: mhi: host: " Julia Lawall
@ 2023-06-23 21:30   ` Jeffrey Hugo
  2023-06-23 21:45     ` Julia Lawall
  2023-06-26 11:46     ` Dan Carpenter
  2023-06-26 14:53   ` Jeffrey Hugo
  1 sibling, 2 replies; 9+ messages in thread
From: Jeffrey Hugo @ 2023-06-23 21:30 UTC (permalink / raw)
  To: Julia Lawall, Manivannan Sadhasivam
  Cc: keescook, kernel-janitors, mhi, linux-arm-msm, linux-kernel

On 6/23/2023 3:14 PM, Julia Lawall wrote:
> Use array_size to protect against multiplication overflows.
> 
> The changes were done using the following Coccinelle semantic patch:
> 
> // <smpl>
> @@
>      expression E1, E2;
>      constant C1, C2;
>      identifier alloc = {vmalloc,vzalloc};
> @@
>      
> (
>        alloc(C1 * C2,...)
> |
>        alloc(
> -           (E1) * (E2)
> +           array_size(E1, E2)
>        ,...)
> )
> // </smpl>
> 
> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
> 
> ---
>   drivers/bus/mhi/host/init.c |    4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
> index f72fcb66f408..34a543a67068 100644
> --- a/drivers/bus/mhi/host/init.c
> +++ b/drivers/bus/mhi/host/init.c
> @@ -759,8 +759,8 @@ static int parse_ch_cfg(struct mhi_controller *mhi_cntrl,
>   	 * so to avoid any memory possible allocation failures, vzalloc is
>   	 * used here
>   	 */
> -	mhi_cntrl->mhi_chan = vzalloc(mhi_cntrl->max_chan *
> -				      sizeof(*mhi_cntrl->mhi_chan));
> +	mhi_cntrl->mhi_chan = vzalloc(array_size(mhi_cntrl->max_chan,
> +				      sizeof(*mhi_cntrl->mhi_chan)));
>   	if (!mhi_cntrl->mhi_chan)
>   		return -ENOMEM;
>   
> 
> 

This doesn't seem like a good fix.

If we've overflowed the multiplication, I don't think we should 
continue, and the function should return an error.  array_size() is 
going to return SIZE_MAX, and it looks like it is possible that 
vzalloc() may be able to allocate that successfully in some scenarios. 
However, that is going to be less memory than parse_ch_cfg() expected to 
allocate, so later on I expect the function will still corrupt memory - 
basically the same result as what the unchecked overflow would do.

I'm not convinced the semantic patch is bringing value as I suspect most 
of the code being patched is in the same situation.

-Jeff

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 10/26] bus: mhi: host: use array_size
  2023-06-23 21:30   ` Jeffrey Hugo
@ 2023-06-23 21:45     ` Julia Lawall
  2023-06-23 22:09       ` Jeffrey Hugo
  2023-06-26 11:46     ` Dan Carpenter
  1 sibling, 1 reply; 9+ messages in thread
From: Julia Lawall @ 2023-06-23 21:45 UTC (permalink / raw)
  To: Jeffrey Hugo
  Cc: Manivannan Sadhasivam, keescook, kernel-janitors, mhi,
	linux-arm-msm, linux-kernel



On Fri, 23 Jun 2023, Jeffrey Hugo wrote:

> On 6/23/2023 3:14 PM, Julia Lawall wrote:
> > Use array_size to protect against multiplication overflows.
> >
> > The changes were done using the following Coccinelle semantic patch:
> >
> > // <smpl>
> > @@
> >      expression E1, E2;
> >      constant C1, C2;
> >      identifier alloc = {vmalloc,vzalloc};
> > @@
> >      (
> >        alloc(C1 * C2,...)
> > |
> >        alloc(
> > -           (E1) * (E2)
> > +           array_size(E1, E2)
> >        ,...)
> > )
> > // </smpl>
> >
> > Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
> >
> > ---
> >   drivers/bus/mhi/host/init.c |    4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
> > index f72fcb66f408..34a543a67068 100644
> > --- a/drivers/bus/mhi/host/init.c
> > +++ b/drivers/bus/mhi/host/init.c
> > @@ -759,8 +759,8 @@ static int parse_ch_cfg(struct mhi_controller
> > *mhi_cntrl,
> >   	 * so to avoid any memory possible allocation failures, vzalloc is
> >   	 * used here
> >   	 */
> > -	mhi_cntrl->mhi_chan = vzalloc(mhi_cntrl->max_chan *
> > -				      sizeof(*mhi_cntrl->mhi_chan));
> > +	mhi_cntrl->mhi_chan = vzalloc(array_size(mhi_cntrl->max_chan,
> > +				      sizeof(*mhi_cntrl->mhi_chan)));
> >   	if (!mhi_cntrl->mhi_chan)
> >   		return -ENOMEM;
> >
> >
>
> This doesn't seem like a good fix.
>
> If we've overflowed the multiplication, I don't think we should continue, and
> the function should return an error.  array_size() is going to return
> SIZE_MAX, and it looks like it is possible that vzalloc() may be able to
> allocate that successfully in some scenarios. However, that is going to be
> less memory than parse_ch_cfg() expected to allocate, so later on I expect the
> function will still corrupt memory - basically the same result as what the
> unchecked overflow would do.
>
> I'm not convinced the semantic patch is bringing value as I suspect most of
> the code being patched is in the same situation.

OK, this just brings the code in line with all the calls updated by Kees's
original patch, cited in the cover letter, which were all the
calls containing a multiplication that existed at the time.

42bc47b35320 ("treewide: Use array_size() in vmalloc()")
fad953ce0b22 ("treewide: Use array_size() in vzalloc()")

julia

>
> -Jeff
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 10/26] bus: mhi: host: use array_size
  2023-06-23 21:45     ` Julia Lawall
@ 2023-06-23 22:09       ` Jeffrey Hugo
  2023-06-23 23:45         ` Kees Cook
  0 siblings, 1 reply; 9+ messages in thread
From: Jeffrey Hugo @ 2023-06-23 22:09 UTC (permalink / raw)
  To: Julia Lawall
  Cc: Manivannan Sadhasivam, keescook, kernel-janitors, mhi,
	linux-arm-msm, linux-kernel

On 6/23/2023 3:45 PM, Julia Lawall wrote:
> 
> 
> On Fri, 23 Jun 2023, Jeffrey Hugo wrote:
> 
>> On 6/23/2023 3:14 PM, Julia Lawall wrote:
>>> Use array_size to protect against multiplication overflows.
>>>
>>> The changes were done using the following Coccinelle semantic patch:
>>>
>>> // <smpl>
>>> @@
>>>       expression E1, E2;
>>>       constant C1, C2;
>>>       identifier alloc = {vmalloc,vzalloc};
>>> @@
>>>       (
>>>         alloc(C1 * C2,...)
>>> |
>>>         alloc(
>>> -           (E1) * (E2)
>>> +           array_size(E1, E2)
>>>         ,...)
>>> )
>>> // </smpl>
>>>
>>> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
>>>
>>> ---
>>>    drivers/bus/mhi/host/init.c |    4 ++--
>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
>>> index f72fcb66f408..34a543a67068 100644
>>> --- a/drivers/bus/mhi/host/init.c
>>> +++ b/drivers/bus/mhi/host/init.c
>>> @@ -759,8 +759,8 @@ static int parse_ch_cfg(struct mhi_controller
>>> *mhi_cntrl,
>>>    	 * so to avoid any memory possible allocation failures, vzalloc is
>>>    	 * used here
>>>    	 */
>>> -	mhi_cntrl->mhi_chan = vzalloc(mhi_cntrl->max_chan *
>>> -				      sizeof(*mhi_cntrl->mhi_chan));
>>> +	mhi_cntrl->mhi_chan = vzalloc(array_size(mhi_cntrl->max_chan,
>>> +				      sizeof(*mhi_cntrl->mhi_chan)));
>>>    	if (!mhi_cntrl->mhi_chan)
>>>    		return -ENOMEM;
>>>
>>>
>>
>> This doesn't seem like a good fix.
>>
>> If we've overflowed the multiplication, I don't think we should continue, and
>> the function should return an error.  array_size() is going to return
>> SIZE_MAX, and it looks like it is possible that vzalloc() may be able to
>> allocate that successfully in some scenarios. However, that is going to be
>> less memory than parse_ch_cfg() expected to allocate, so later on I expect the
>> function will still corrupt memory - basically the same result as what the
>> unchecked overflow would do.
>>
>> I'm not convinced the semantic patch is bringing value as I suspect most of
>> the code being patched is in the same situation.
> 
> OK, this just brings the code in line with all the calls updated by Kees's
> original patch, cited in the cover letter, which were all the
> calls containing a multiplication that existed at the time.
> 
> 42bc47b35320 ("treewide: Use array_size() in vmalloc()")
> fad953ce0b22 ("treewide: Use array_size() in vzalloc()")

Eh.  I "git show fad953ce0b22" and it doesn't really tell me much.  The 
commit asserts that uses of vzalloc() and multiplication need 
array_size(), but doesn't really explain why.

This looks like a brute force automated update with no thought and I 
fear the result of this change is the conclusion that we've solved 
multiplication overflow, when it doesn't look like we've really done 
much.  Sure, the multiplication gets capped, but can the code actually 
handle that?

I should probably run the numbers, but with the relevant spec capping 
the number of channels at 256, I don't think we can realistically 
approach overflow, even on a 32-bit system.  However, having correct 
code that is inherently safe seems like a good idea and so I feel this 
function has an issue.  I just don't think this automated conversion 
meaningfully does anything to improve the code here.

Kees, would you please chime in and educate me here?  I feel like I'm 
missing something important here.

-Jeff

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 10/26] bus: mhi: host: use array_size
  2023-06-23 22:09       ` Jeffrey Hugo
@ 2023-06-23 23:45         ` Kees Cook
  2023-06-24 16:06           ` Jeffrey Hugo
  0 siblings, 1 reply; 9+ messages in thread
From: Kees Cook @ 2023-06-23 23:45 UTC (permalink / raw)
  To: Jeffrey Hugo
  Cc: Julia Lawall, Manivannan Sadhasivam, kernel-janitors, mhi,
	linux-arm-msm, linux-kernel

On Fri, Jun 23, 2023 at 04:09:46PM -0600, Jeffrey Hugo wrote:
> Kees, would you please chime in and educate me here?  I feel like I'm
> missing something important here.

The array_size() family will saturate at SIZE_MAX (rather than potentially
wrapping around). No allocator can fulfil a 18446744073709551615 byte
(18 exabyte) allocation. :) So the NULL return value will (hopefully)
trigger an error path.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 10/26] bus: mhi: host: use array_size
  2023-06-23 23:45         ` Kees Cook
@ 2023-06-24 16:06           ` Jeffrey Hugo
  0 siblings, 0 replies; 9+ messages in thread
From: Jeffrey Hugo @ 2023-06-24 16:06 UTC (permalink / raw)
  To: Kees Cook
  Cc: Julia Lawall, Manivannan Sadhasivam, kernel-janitors, mhi,
	linux-arm-msm, linux-kernel

On 6/23/2023 5:45 PM, Kees Cook wrote:
> On Fri, Jun 23, 2023 at 04:09:46PM -0600, Jeffrey Hugo wrote:
>> Kees, would you please chime in and educate me here?  I feel like I'm
>> missing something important here.
> 
> The array_size() family will saturate at SIZE_MAX (rather than potentially
> wrapping around). No allocator can fulfil a 18446744073709551615 byte
> (18 exabyte) allocation. :) So the NULL return value will (hopefully)
> trigger an error path.
> 

Fair enough, that handles the 64-bit usecase.  I'm guessing the 
assumption is that on a 32-bit usecase where size_t is ~4GB, there won't 
actually be 4GB to allocate and things will also fail.  So far, so good.

What about a 32-bit system with something like ARM's LPAE (Large 
Physical Address Extension) where the host is 32-bit, and so size_t 
would be ~4GB (as far as I can tell) but phys_addr_t is larger than 
that, and so we can have/access more than 4GB of resources?  Lets see, 
ignoring that its a 13 year old feature and probably not in circulation 
anymore, probably still can't satisfy a 4GB allocation since you'd need 
to map all of it to address it, and part of the address space is surely 
reserved for other things.

Ok, I think I'm convinced.  I'm going to sleep on it, but I suspect all 
will still be good early next week.

Thank you for the explanation.

-Jeff

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 10/26] bus: mhi: host: use array_size
  2023-06-23 21:30   ` Jeffrey Hugo
  2023-06-23 21:45     ` Julia Lawall
@ 2023-06-26 11:46     ` Dan Carpenter
  1 sibling, 0 replies; 9+ messages in thread
From: Dan Carpenter @ 2023-06-26 11:46 UTC (permalink / raw)
  To: Jeffrey Hugo
  Cc: Julia Lawall, Manivannan Sadhasivam, keescook, kernel-janitors,
	mhi, linux-arm-msm, linux-kernel

On Fri, Jun 23, 2023 at 03:30:36PM -0600, Jeffrey Hugo wrote:
> On 6/23/2023 3:14 PM, Julia Lawall wrote:
> > Use array_size to protect against multiplication overflows.
> > 
> > The changes were done using the following Coccinelle semantic patch:
> > 
> > // <smpl>
> > @@
> >      expression E1, E2;
> >      constant C1, C2;
> >      identifier alloc = {vmalloc,vzalloc};
> > @@
> > (
> >        alloc(C1 * C2,...)
> > |
> >        alloc(
> > -           (E1) * (E2)
> > +           array_size(E1, E2)
> >        ,...)
> > )
> > // </smpl>
> > 
> > Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
> > 
> > ---
> >   drivers/bus/mhi/host/init.c |    4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
> > index f72fcb66f408..34a543a67068 100644
> > --- a/drivers/bus/mhi/host/init.c
> > +++ b/drivers/bus/mhi/host/init.c
> > @@ -759,8 +759,8 @@ static int parse_ch_cfg(struct mhi_controller *mhi_cntrl,
> >   	 * so to avoid any memory possible allocation failures, vzalloc is
> >   	 * used here
> >   	 */
> > -	mhi_cntrl->mhi_chan = vzalloc(mhi_cntrl->max_chan *
> > -				      sizeof(*mhi_cntrl->mhi_chan));
> > +	mhi_cntrl->mhi_chan = vzalloc(array_size(mhi_cntrl->max_chan,
> > +				      sizeof(*mhi_cntrl->mhi_chan)));
> >   	if (!mhi_cntrl->mhi_chan)
> >   		return -ENOMEM;
> > 
> > 
> 
> This doesn't seem like a good fix.
> 
> If we've overflowed the multiplication, I don't think we should continue,
> and the function should return an error.  array_size() is going to return
> SIZE_MAX, and it looks like it is possible that vzalloc() may be able to
> allocate that successfully in some scenarios.

Nope.  You can never allocate more that size_t because that's the
highest number that the kernel allocation functions can accept.

Obviously on 64bit size_t is unbelievably large.  If I remember right,
on 32bit you didn't used to be able to allocate more than 2GB without
doing all sorts of tricks.  And everyone deleted those tricks when 64bit
machines became super common.

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 10/26] bus: mhi: host: use array_size
  2023-06-23 21:14 ` [PATCH 10/26] bus: mhi: host: " Julia Lawall
  2023-06-23 21:30   ` Jeffrey Hugo
@ 2023-06-26 14:53   ` Jeffrey Hugo
  1 sibling, 0 replies; 9+ messages in thread
From: Jeffrey Hugo @ 2023-06-26 14:53 UTC (permalink / raw)
  To: Julia Lawall, Manivannan Sadhasivam
  Cc: keescook, kernel-janitors, mhi, linux-arm-msm, linux-kernel

On 6/23/2023 3:14 PM, Julia Lawall wrote:
> Use array_size to protect against multiplication overflows.
> 
> The changes were done using the following Coccinelle semantic patch:
> 
> // <smpl>
> @@
>      expression E1, E2;
>      constant C1, C2;
>      identifier alloc = {vmalloc,vzalloc};
> @@
>      
> (
>        alloc(C1 * C2,...)
> |
>        alloc(
> -           (E1) * (E2)
> +           array_size(E1, E2)
>        ,...)
> )
> // </smpl>
> 
> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
> 

Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-06-26 14:53 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-23 21:14 [PATCH 00/26] use array_size Julia Lawall
2023-06-23 21:14 ` [PATCH 10/26] bus: mhi: host: " Julia Lawall
2023-06-23 21:30   ` Jeffrey Hugo
2023-06-23 21:45     ` Julia Lawall
2023-06-23 22:09       ` Jeffrey Hugo
2023-06-23 23:45         ` Kees Cook
2023-06-24 16:06           ` Jeffrey Hugo
2023-06-26 11:46     ` Dan Carpenter
2023-06-26 14:53   ` Jeffrey Hugo

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).