Re: [Bug 199037] New: Kernel bug at mm/hugetlb.c:741

[Nic Losby <blurbdust@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

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 <mike.kravetz@oracle.com>
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
>

[-- Attachment #2: Type: text/html, Size: 2548 bytes --]