Bug 216911

Summary: get_unmapped_area returns addresses below mmap_min_addr
Product: Memory Management Reporter: Amanieu d'Antras (amanieu)
Component: OtherAssignee: Andrew Morton (akpm)
Status: NEW ---    
Severity: normal CC: howlett, nicknitewolf, tad
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: v6.1 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: Program which demonstrates this issue

Description Amanieu d'Antras 2023-01-11 02:10:02 UTC
Created attachment 303572 [details]
Program which demonstrates this issue

The vm_unmapped_area function doesn't seem to respect info.low_limit and will sometimes return an address below this limit. This can result in addresses below mmap_min_addr being returned.

I bisected it down to this range of commits (I stopped since I was hitting kernel crashes):
3499a13168da mm/mmap: use maple tree for unmapped_area{_topdown}
7fdbd37da5c6 mm/mmap: use the maple tree for find_vma_prev() instead of the rbtree
be8432e7166e mm/mmap: use the maple tree in find_vma() instead of the rbtree.
2e3af1db1744 mmap: use the VMA iterator in count_vma_pages_range()
f39af05949a4 mm: add VMA iterator
d4af56c5c7c6 mm: start tracking VMAs with maple tree

I've attached a test program which attempts to allocate the entire address space. On affected kernels, this triggers one of the 2 assertions (depending on whether you are running as root):
- NULL is returned, which means memory below mmap_min_addr was allocated.
- EPERM is returned, which really shouldn't happen when MAP_FIXED is not used (ENOMEM should be returned instead).
Comment 1 Liam R. Howlett 2023-01-11 19:21:29 UTC
Thanks for the report & the reproducer.  This is very helpful.

The crash you are hitting in that git id range is actually something I added to ensure I was returning the same value as was being returned before.

Although the bug would not be hit until:
3499a13168da mm/mmap: use maple tree for unmapped_area{_topdown}

It would have caused a BUG_ON starting in:
d4af56c5c7c6 mm: start tracking VMAs with maple tree

I will email a fix soon.
Comment 2 Liam R. Howlett 2023-01-13 02:05:39 UTC
Just for completeness, here's a link to the email:

https://lore.kernel.org/linux-mm/20230111200136.1851322-1-Liam.Howlett@oracle.com/
Comment 3 tad 2023-03-20 20:36:00 UTC
I've been consistently slamming into this on 6.1.6 (earliest shipped on Fedora) through 6.2.7.

> dex2oatd F 01-18 16:30:44 1390069 1390069 mem_map_arena_pool.cc:65] Check
> failed: map.IsValid() Failed anonymous mmap((nil), 131072, 0x3, 0x22, -1, 0):
> Cannot allocate memory. See process maps in the log.

Using 6.0.18 has been my only workaround.

I can report to Red Hat BZ as per policy, but the linked patch above never had any response.
Comment 4 Liam R. Howlett 2023-03-21 03:11:39 UTC
The linked patch landed in 6.1.11 as commit 82587c0e2735 ("maple_tree: fix mas_empty_area_rev() lower bound validation")

See the change log here:
https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.11


It also landed in v6.2-rc7 as commit 7327e8111adb ("maple_tree: fix mas_empty_area_rev() lower bound validation")

Can you provide some more information to recreate your issue?
Comment 5 Liam R. Howlett 2023-03-21 03:29:19 UTC
This looks a lot like a bug reported on the 2nd of march:
https://lore.kernel.org/linux-mm/cb8dc31a-fef2-1d09-f133-e9f7b9f9e77a@sony.com/

Although, the flags in this particular mmap does not include the MAP_32BIT flag.

The patch for second issue has not made it upstream yet, but is in the mm-unstable and mm-hotfixes-unstable branch.

See the link below for the fix for the second issue:
https://lore.kernel.org/linux-mm/20230307180247.2220303-1-Liam.Howlett@oracle.com/
Comment 6 Nicholas Lim 2023-05-13 20:25:29 UTC
Patches introduced in 6.2.13 seemed to have reintroduced the regressions mentioned here:

```
dex2oatd F 05-05 17:46:36 182488 182488 mem_map_arena_pool.cc:65] Check failed: map.IsValid() Failed anonymous mmap((nil), 131072, 0x3, 0x22, -1, 0): Cannot allocate memory. See process maps in the log.
```
Comment 7 Liam R. Howlett 2023-05-15 14:40:36 UTC
There is a fix in mm-unstable that is making its way to fixing this now.

https://lore.kernel.org/linux-mm/20230505145829.74574-1-zhangpeng.00@bytedance.com/
Comment 8 Nicholas Lim 2023-05-17 10:39:33 UTC
(In reply to Liam R. Howlett from comment #7)
> There is a fix in mm-unstable that is making its way to fixing this now.
> 
> https://lore.kernel.org/linux-mm/20230505145829.74574-1-zhangpeng.
> 00@bytedance.com/

Do you have any idea when it will be entering stable releases? This regression affects all stable, mainline, and 6.1.y LTS
Comment 9 Liam R. Howlett 2023-05-23 01:43:25 UTC
This patch has landed in 6.4-rc3 so it should go to stable shortly