Michael Ellerman [off-list ref] writes:

"Aneesh Kumar K.V" [off-list ref] writes:

quoted

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

quoted

CC: Laurent Dufour <redacted>
Signed-off-by: Aneesh Kumar K.V <redacted>

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