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: syzbot+353c7be4964c6253f24a@xxxxxxxxxxxxxxxxxxxxxxxxx Closes: https://lore.kernel.org/all/000000000000094fdd05faa4d3a4@xxxxxxxxxx Signed-off-by: Jason Gunthorpe <jgg@xxxxxxxxxx> --- 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 <david@xxxxxxxxxx> -- Cheers, David / dhildenb
