mm/gup: Do not return 0 from pin_user_pages_fast() for bad args

Commit Message

Jason Gunthorpe June 19, 2023, 6:27 p.m. UTC

These routines are not intended to return zero, the callers cannot do
anything sane with a 0 return. They should return an error which means
future calls to GUP will not succeed, or they should return some non-zero
number of pinned pages which means GUP should be called again.

If start + nr_pages overflows it should return -EOVERFLOW to signal the
arguments are invalid.

Syzkaller keeps tripping on this when fuzzing GUP arguments.

Reported-by: [e-mail]
Closes: https://lore.kernel.org/all/[e-mail]
Signed-off-by: Jason Gunthorpe <[e-mail]>
---
 mm/gup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: b3eacbbcd0dab69ed4c44cbd2d2d72b016762b17

Comments

John Hubbard June 20, 2023, 1:38 a.m. UTC | #1

On 6/19/23 11:27, Jason Gunthorpe wrote:
> These routines are not intended to return zero, the callers cannot do
> anything sane with a 0 return. They should return an error which means
> future calls to GUP will not succeed, or they should return some non-zero
> number of pinned pages which means GUP should be called again.
> 
> If start + nr_pages overflows it should return -EOVERFLOW to signal the
> arguments are invalid.
> 
> Syzkaller keeps tripping on this when fuzzing GUP arguments.
> 
> Reported-by: [e-mail]
> Closes: https://lore.kernel.org/all/[e-mail]
> Signed-off-by: Jason Gunthorpe <[e-mail]>
> ---
>   mm/gup.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: John Hubbard <[e-mail]>


thanks,

Lorenzo Stoakes June 20, 2023, 9:20 p.m. UTC | #2

On Mon, Jun 19, 2023 at 03:27:25PM -0300, Jason Gunthorpe wrote:
> These routines are not intended to return zero, the callers cannot do
> anything sane with a 0 return. They should return an error which means
> future calls to GUP will not succeed, or they should return some non-zero
> number of pinned pages which means GUP should be called again.
>
> If start + nr_pages overflows it should return -EOVERFLOW to signal the
> arguments are invalid.

It's crazy that it wasn't doing this before.

>
> Syzkaller keeps tripping on this when fuzzing GUP arguments.
>
> Reported-by: [e-mail]
> Closes: https://lore.kernel.org/all/[e-mail]
> Signed-off-by: Jason Gunthorpe <[e-mail]>
> ---
>  mm/gup.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index bbe4162365933e..36c587fec574fd 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2969,7 +2969,7 @@ static int internal_get_user_pages_fast(unsigned long start,
>  	start = untagged_addr(start) & PAGE_MASK;
>  	len = nr_pages << PAGE_SHIFT;
>  	if (check_add_overflow(start, len, &end))
> -		return 0;
> +		return -EOVERFLOW;
>  	if (end > TASK_SIZE_MAX)
>  		return -EFAULT;
>  	if (unlikely(!access_ok((void __user *)start, len)))
>
> base-commit: b3eacbbcd0dab69ed4c44cbd2d2d72b016762b17
> --
> 2.40.1
>
>

Reviewed-by: Lorenzo Stoakes <[e-mail]>

David Hildenbrand June 21, 2023, 11:24 a.m. UTC | #3

On 19.06.23 20:27, Jason Gunthorpe wrote:
> These routines are not intended to return zero, the callers cannot do
> anything sane with a 0 return. They should return an error which means
> future calls to GUP will not succeed, or they should return some non-zero
> number of pinned pages which means GUP should be called again.
> 
> If start + nr_pages overflows it should return -EOVERFLOW to signal the
> arguments are invalid.
> 
> Syzkaller keeps tripping on this when fuzzing GUP arguments.
> 
> Reported-by: [e-mail]
> Closes: https://lore.kernel.org/all/[e-mail]
> Signed-off-by: Jason Gunthorpe <[e-mail]>
> ---
>   mm/gup.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/gup.c b/mm/gup.c
> index bbe4162365933e..36c587fec574fd 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2969,7 +2969,7 @@ static int internal_get_user_pages_fast(unsigned long start,
>   	start = untagged_addr(start) & PAGE_MASK;
>   	len = nr_pages << PAGE_SHIFT;
>   	if (check_add_overflow(start, len, &end))
> -		return 0;
> +		return -EOVERFLOW;

I'm curious if there is any sane use case where that could actually 
trigger. Smells like something that should be a WARN_ON_ONCE(), but 
maybe some callers simply pass through what user-space gave them.

Anyhow.

Reviewed-by: David Hildenbrand <[e-mail]>

Jason Gunthorpe June 21, 2023, 11:38 a.m. UTC | #4

On Wed, Jun 21, 2023 at 01:24:14PM +0200, David Hildenbrand wrote:
> > diff --git a/mm/gup.c b/mm/gup.c
> > index bbe4162365933e..36c587fec574fd 100644
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -2969,7 +2969,7 @@ static int internal_get_user_pages_fast(unsigned long start,
> >   	start = untagged_addr(start) & PAGE_MASK;
> >   	len = nr_pages << PAGE_SHIFT;
> >   	if (check_add_overflow(start, len, &end))
> > -		return 0;
> > +		return -EOVERFLOW;
> 
> I'm curious if there is any sane use case where that could actually trigger.
> Smells like something that should be a WARN_ON_ONCE(), but maybe some
> callers simply pass through what user-space gave them.

Yes, that is pretty common to just pass through.

Thanks,
Jason

Patch

diff --git a/mm/gup.c b/mm/gup.c
index bbe4162365933e..36c587fec574fd 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2969,7 +2969,7 @@  static int internal_get_user_pages_fast(unsigned long start,
 	start = untagged_addr(start) & PAGE_MASK;
 	len = nr_pages << PAGE_SHIFT;
 	if (check_add_overflow(start, len, &end))
-		return 0;
+		return -EOVERFLOW;
 	if (end > TASK_SIZE_MAX)
 		return -EFAULT;
 	if (unlikely(!access_ok((void __user *)start, len)))