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?
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 <mike.kravetz@xxxxxxxxxx> 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(). This is similar to the issue addressed in 045c7a3f ("fix offset overflow
>>
>> 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
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
