linux-kernel - Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 23 Aug 2016 18:00:30 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     "Kani, Toshimitsu" <toshi.kani@....com>
Cc:     "Mulumudi, Abhilash Kumar" <m.abhilash-kumar@....com>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "brian.starkey@....com" <brian.starkey@....com>
Subject: Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu <toshi.kani@....com> wrote:
> On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
>> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani <toshi.kani@....com>
>> wrote:
>  :
>> I'm not sure about this fix.  The point of honoring
>> vmem_altmap_offset() is because a portion of the resource that is
>> passed to devm_memremap_pages() also contains the metadata info block
>> for the device.  The offset says "use everything past this point for
>> pages".  This may work for avoiding a crash, but it may corrupt info
>> block metadata in the process.  Can you provide more information
>> about the failing scenario to be sure that we are not triggering a
>> fault on an address that is not meant to have a page mapping?  I.e.
>> what is the host physical address of the page that caused this fault,
>> and is it valid?
>
> The fault address in question was the 2nd page of an NVDIMM range.  I
> assumed this fault address was valid and needed to be handled.  Here is
> some info about the base and patched cases.  Let me know if you need
> more info.
>
> Base
> ====
>
> The following NVDIMM range was set to /dev/dax.
>
> /proc/iomem
> 480000000-87fffffff : Persistent Memory
>
> devm_memremap_pages() initialized struct page from 0x490200-0x87ffff.

This seems like the start of the trouble.  What happened to the first
1GB of the address range?  I'm assuming the 'align' attribute is set
to 2MB because we start at a pfn offset of 0x200, but this should be
starting at 0x480200.