linux-kernel - Re: Panic when insmod nfit

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 12 Sep 2016 19:50:22 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     ryan chen <ryan.chan105@...il.com>
Cc:     "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Panic when insmod nfit_test.ko

On Mon, Sep 12, 2016 at 7:30 PM, ryan chen <ryan.chan105@...il.com> wrote:
> Hi all,
> Recently I'm trying to check the testing suite of nfit_test for nvdimm
> on 4.8-rc5, and system got panic once insmod nfit_test.ko ,
> I've checked the RIP, I guess it panics due to NULL
> nvdimm_map pointer, i.e., accessing nvdimm_map->mem,
> so I have a question that, should we check the return value of
> alloc_nvdimm_map if it failed:
>
> --- a/drivers/nvdimm/core.c
> +++ b/drivers/nvdimm/core.c
> @@ -171,6 +171,9 @@ void *devm_nvdimm_memremap(struct device *dev,
> resource_size_t offset,
>                 kref_get(&nvdimm_map->kref);
>         nvdimm_bus_unlock(dev);
>
> +       if (!nvdimm_map)
> +               return NULL;
> +
>         if (devm_add_action_or_reset(dev, nvdimm_map_put, nvdimm_map))
>                 return NULL;
> But why we got NULL nvdimm_map is still unknown,
> please let me know if you need any information. Thanks.

Thanks for the report.  We do need to check if alloc_nvdimm_map fails.
My guess as to why it is failing the call to request_mem_region().
Can you try the attached patch, and send the kernel log as well as the
contents of /proc/iomem?

View attachment "libnvdimm-fix.patch" of type "text/x-patch" (1373 bytes)