mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Re: [PATCH] udmabuf: Fix a potential (and unlikely) access to unallocated memory
  2023-09-18 18:46 [PATCH] udmabuf: Fix a potential (and unlikely) access to unallocated memory Christophe JAILLET
@ 2023-09-18  3:10 ` Gustavo A. R. Silva
  2023-09-18 19:22   ` Christophe JAILLET
  0 siblings, 1 reply; 4+ messages in thread
From: Gustavo A. R. Silva @ 2023-09-18  3:10 UTC (permalink / raw)
  To: Christophe JAILLET, Gerd Hoffmann, Sumit Semwal,
	Christian König, Daniel Vetter
  Cc: linux-hardening, linux-kernel, kernel-janitors, dri-devel,
	linux-media, linaro-mm-sig



On 9/18/23 12:46, Christophe JAILLET wrote:
> If 'list_limit' is set to a very high value, 'lsize' computation could
> overflow if 'head.count' is big enough.
> 
> In such a case, udmabuf_create() will access to memory beyond 'list'.
> 
> Use size_mul() to saturate the value, and have memdup_user() fail.
> 
> Fixes: fbb0de795078 ("Add udmabuf misc device")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
>   drivers/dma-buf/udmabuf.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index c40645999648..fb4c4b5b3332 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -314,13 +314,13 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg)
>   	struct udmabuf_create_list head;
>   	struct udmabuf_create_item *list;
>   	int ret = -EINVAL;
> -	u32 lsize;
> +	size_t lsize;
>   
>   	if (copy_from_user(&head, (void __user *)arg, sizeof(head)))
>   		return -EFAULT;
>   	if (head.count > list_limit)
>   		return -EINVAL;
> -	lsize = sizeof(struct udmabuf_create_item) * head.count;
> +	lsize = size_mul(sizeof(struct udmabuf_create_item), head.count);
>   	list = memdup_user((void __user *)(arg + sizeof(head)), lsize);
>   	if (IS_ERR(list))
>   		return PTR_ERR(list);

How about this, and we get rid of `lsize`:

diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index c40645999648..5cf9d849aaa8 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -314,14 +314,13 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg)
         struct udmabuf_create_list head;
         struct udmabuf_create_item *list;
         int ret = -EINVAL;
-       u32 lsize;

         if (copy_from_user(&head, (void __user *)arg, sizeof(head)))
                 return -EFAULT;
         if (head.count > list_limit)
                 return -EINVAL;
-       lsize = sizeof(struct udmabuf_create_item) * head.count;
-       list = memdup_user((void __user *)(arg + sizeof(head)), lsize);
+       list = memdup_user((void __user *)(arg + sizeof(head)),
+                          size_mul(sizeof(*list), head.count));
         if (IS_ERR(list))
                 return PTR_ERR(list);


--
Gustavo

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

* [PATCH] udmabuf: Fix a potential (and unlikely) access to unallocated memory
@ 2023-09-18 18:46 Christophe JAILLET
  2023-09-18  3:10 ` Gustavo A. R. Silva
  0 siblings, 1 reply; 4+ messages in thread
From: Christophe JAILLET @ 2023-09-18 18:46 UTC (permalink / raw)
  To: Gerd Hoffmann, Sumit Semwal, Christian König, Daniel Vetter
  Cc: linux-hardening, linux-kernel, kernel-janitors,
	Christophe JAILLET, dri-devel, linux-media, linaro-mm-sig

If 'list_limit' is set to a very high value, 'lsize' computation could
overflow if 'head.count' is big enough.

In such a case, udmabuf_create() will access to memory beyond 'list'.

Use size_mul() to saturate the value, and have memdup_user() fail.

Fixes: fbb0de795078 ("Add udmabuf misc device")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
 drivers/dma-buf/udmabuf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index c40645999648..fb4c4b5b3332 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -314,13 +314,13 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg)
 	struct udmabuf_create_list head;
 	struct udmabuf_create_item *list;
 	int ret = -EINVAL;
-	u32 lsize;
+	size_t lsize;
 
 	if (copy_from_user(&head, (void __user *)arg, sizeof(head)))
 		return -EFAULT;
 	if (head.count > list_limit)
 		return -EINVAL;
-	lsize = sizeof(struct udmabuf_create_item) * head.count;
+	lsize = size_mul(sizeof(struct udmabuf_create_item), head.count);
 	list = memdup_user((void __user *)(arg + sizeof(head)), lsize);
 	if (IS_ERR(list))
 		return PTR_ERR(list);
-- 
2.34.1


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

* Re: [PATCH] udmabuf: Fix a potential (and unlikely) access to unallocated memory
  2023-09-18  3:10 ` Gustavo A. R. Silva
@ 2023-09-18 19:22   ` Christophe JAILLET
  2023-09-24  2:57     ` Kees Cook
  0 siblings, 1 reply; 4+ messages in thread
From: Christophe JAILLET @ 2023-09-18 19:22 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Gerd Hoffmann, Sumit Semwal,
	Christian König, Daniel Vetter
  Cc: linux-hardening, linux-kernel, kernel-janitors, dri-devel,
	linux-media, linaro-mm-sig

Le 18/09/2023 à 05:10, Gustavo A. R. Silva a écrit :
> 
> 
> On 9/18/23 12:46, Christophe JAILLET wrote:
>> If 'list_limit' is set to a very high value, 'lsize' computation could
>> overflow if 'head.count' is big enough.
>>
>> In such a case, udmabuf_create() will access to memory beyond 'list'.
>>
>> Use size_mul() to saturate the value, and have memdup_user() fail.
>>
>> Fixes: fbb0de795078 ("Add udmabuf misc device")
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>>   drivers/dma-buf/udmabuf.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
>> index c40645999648..fb4c4b5b3332 100644
>> --- a/drivers/dma-buf/udmabuf.c
>> +++ b/drivers/dma-buf/udmabuf.c
>> @@ -314,13 +314,13 @@ static long udmabuf_ioctl_create_list(struct 
>> file *filp, unsigned long arg)
>>       struct udmabuf_create_list head;
>>       struct udmabuf_create_item *list;
>>       int ret = -EINVAL;
>> -    u32 lsize;
>> +    size_t lsize;
>>       if (copy_from_user(&head, (void __user *)arg, sizeof(head)))
>>           return -EFAULT;
>>       if (head.count > list_limit)
>>           return -EINVAL;
>> -    lsize = sizeof(struct udmabuf_create_item) * head.count;
>> +    lsize = size_mul(sizeof(struct udmabuf_create_item), head.count);
>>       list = memdup_user((void __user *)(arg + sizeof(head)), lsize);
>>       if (IS_ERR(list))
>>           return PTR_ERR(list);
> 
> How about this, and we get rid of `lsize`:

Keeping or removing lsize is mostly a matter of taste, I think.

Using sizeof(*list) is better.

Let see if there are some other comments, and I'll send a v2.

Thanks for the feed-back.

CJ

> 
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index c40645999648..5cf9d849aaa8 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -314,14 +314,13 @@ static long udmabuf_ioctl_create_list(struct file 
> *filp, unsigned long arg)
>          struct udmabuf_create_list head;
>          struct udmabuf_create_item *list;
>          int ret = -EINVAL;
> -       u32 lsize;
> 
>          if (copy_from_user(&head, (void __user *)arg, sizeof(head)))
>                  return -EFAULT;
>          if (head.count > list_limit)
>                  return -EINVAL;
> -       lsize = sizeof(struct udmabuf_create_item) * head.count;
> -       list = memdup_user((void __user *)(arg + sizeof(head)), lsize);
> +       list = memdup_user((void __user *)(arg + sizeof(head)),
> +                          size_mul(sizeof(*list), head.count));
>          if (IS_ERR(list))
>                  return PTR_ERR(list);
> 
> 
> -- 
> Gustavo
> 


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

* Re: [PATCH] udmabuf: Fix a potential (and unlikely) access to unallocated memory
  2023-09-18 19:22   ` Christophe JAILLET
@ 2023-09-24  2:57     ` Kees Cook
  0 siblings, 0 replies; 4+ messages in thread
From: Kees Cook @ 2023-09-24  2:57 UTC (permalink / raw)
  To: Christophe JAILLET
  Cc: Gustavo A. R. Silva, Gerd Hoffmann, Sumit Semwal,
	Christian König, Daniel Vetter, linux-hardening,
	linux-kernel, kernel-janitors, dri-devel, linux-media,
	linaro-mm-sig

On Mon, Sep 18, 2023 at 09:22:44PM +0200, Christophe JAILLET wrote:
> Le 18/09/2023 à 05:10, Gustavo A. R. Silva a écrit :
> > 
> > 
> > On 9/18/23 12:46, Christophe JAILLET wrote:
> > > If 'list_limit' is set to a very high value, 'lsize' computation could
> > > overflow if 'head.count' is big enough.
> > > 
> > > In such a case, udmabuf_create() will access to memory beyond 'list'.
> > > 
> > > Use size_mul() to saturate the value, and have memdup_user() fail.
> > > 
> > > Fixes: fbb0de795078 ("Add udmabuf misc device")
> > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > > ---
> > >   drivers/dma-buf/udmabuf.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> > > index c40645999648..fb4c4b5b3332 100644
> > > --- a/drivers/dma-buf/udmabuf.c
> > > +++ b/drivers/dma-buf/udmabuf.c
> > > @@ -314,13 +314,13 @@ static long udmabuf_ioctl_create_list(struct
> > > file *filp, unsigned long arg)
> > >       struct udmabuf_create_list head;
> > >       struct udmabuf_create_item *list;
> > >       int ret = -EINVAL;
> > > -    u32 lsize;
> > > +    size_t lsize;
> > >       if (copy_from_user(&head, (void __user *)arg, sizeof(head)))
> > >           return -EFAULT;
> > >       if (head.count > list_limit)
> > >           return -EINVAL;
> > > -    lsize = sizeof(struct udmabuf_create_item) * head.count;
> > > +    lsize = size_mul(sizeof(struct udmabuf_create_item), head.count);
> > >       list = memdup_user((void __user *)(arg + sizeof(head)), lsize);
> > >       if (IS_ERR(list))
> > >           return PTR_ERR(list);
> > 
> > How about this, and we get rid of `lsize`:
> 
> Keeping or removing lsize is mostly a matter of taste, I think.

I'm on the fence, but kind of lean towards keeping lsize, but I think
it's fine either way.

> Using sizeof(*list) is better.

That I agree with, yes.

> Let see if there are some other comments, and I'll send a v2.

I note that this looks like a use-case for the very recently proposed
memdup_array_user():
https://lore.kernel.org/all/ACD75DAA-AF42-486C-B44B-9272EF302E3D@kernel.org/

(i.e. a built-in size_mul)

-Kees

-- 
Kees Cook

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

end of thread, other threads:[~2023-09-24  2:57 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-18 18:46 [PATCH] udmabuf: Fix a potential (and unlikely) access to unallocated memory Christophe JAILLET
2023-09-18  3:10 ` Gustavo A. R. Silva
2023-09-18 19:22   ` Christophe JAILLET
2023-09-24  2:57     ` Kees Cook

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®