Awesome. Let me know if you need anything else from me. I can keep testing kernel versions if requested. Getting a CVE is something that is high on my bucket list. Even though this is only Denial of Service at best, what are the chances this would be assigned a CVE? On Tue, Mar 6, 2018 at 6:31 PM, Mike Kravetz wrote: > On 03/06/2018 01:46 PM, Mike Kravetz wrote: > > On 03/06/2018 01:31 PM, Andrew Morton wrote: > >> > >> That's VM_BUG_ON(resv_map->adds_in_progress) in resv_map_release(). > >> > >> Do you know if earlier kernel versions are affected? > >> > >> It looks quite bisectable. Does the crash happen every time the test > >> program is run? > > > > I'll take a look. There was a previous bug in this area: > > ff8c0c53: mm/hugetlb.c: don't call region_abort if region_chg fails > > This is similar to the issue addressed in 045c7a3f ("fix offset overflow > in hugetlbfs mmap"). The problem here is that the pgoff argument passed > to remap_file_pages() is 0x20000000000000. In the process of converting > this to a page offset and putting it in vm_pgoff, and then converting back > to bytes to compute mapping length we end up with 0. We ultimately end > up passing (from,to) page offsets into hugetlbfs where from is greater > than to. :( This confuses the heck out the the huge page reservation code > as the 'negative' range looks like an error and we never complete the > reservation process and leave the 'adds_in_progress'. > > This issue has existed for a long time. The VM_BUG_ON just happens to > catch the situation which was previously not reported or had some other > side effect. Commit 045c7a3f tried to catch these overflow issues when > converting types, but obviously missed this one. I can easily add a test > for this specific value/condition, but want to think about it a little > more and see if there is a better way to catch all of these. > > -- > Mike Kravetz >