Subject: Re: [PATCH] powerpc/mm: Handle mmap_min_addr correctly in get_unmapped_area callback

From: "Aneesh Kumar K.V" <[email-masked]>
Date: Fri, 22 Feb 2019 20:51:00 +0530

Michael Ellerman <[email-masked]> writes:

> "Aneesh Kumar K.V" <[email-masked]> writes:
>
>> After we ALIGN up the address we need to make sure we didn't overflow
>> and resulted in zero address. In that case, we need to make sure that
>> the returned address is greater than mmap_min_addr.
>>
>> Also when doing top-down search the low_limit is not PAGE_SIZE but rather
>> max(PAGE_SIZE, mmap_min_addr). This handle cases in which mmap_min_addr >
>> PAGE_SIZE.
>>
>> This fixes selftest va_128TBswitch --run-hugetlb reporting failures when
>> run as non root user for
>>
>> mmap(-1, MAP_HUGETLB)
>> mmap(-1, MAP_HUGETLB)
>>
>> We also avoid the first mmap(-1, MAP_HUGETLB) returning NULL address as mmap address
>> with this change
>
> So we think this is not a security issue, because it only affects
> whether we choose an address below mmap_min_addr, not whether we
> actually allow that address to be mapped.
>
> ie. there are existing capability checks to prevent a user mapping below
> mmap_min_addr and those will still be honoured even without this fix.
>
> However there is a bug in that a non-root user requesting address -1
> will be given address 0 which will then fail, whereas they should have
> been given something else that would have succeeded.
>
> Did I get that all right?

Correct

>> CC: Laurent Dufour <[email-masked]>
>> Signed-off-by: Aneesh Kumar K.V <[email-masked]>
>
> Seems like this should have a Fixes: tag?

I guess the hugetlb is 

Fixes: 484837601d4d ("powerpc/mm: Add radix support for hugetlb")

The slice related fix is possibly

Fixes: fba2369e6ceb ("mm: use vm_unmapped_area() on powerpc architecture")

This introduced info.low_limit which we are fixing in the patch. But
a similar logic was present even before via.

Fixes: d0f13e3c20b6 ("[POWERPC] Introduce address space "slices"")

-aneesh