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] [day] [month] [year] [list]
Date:   Mon, 19 Dec 2016 13:37:35 -0800
From:   David Daney <ddaney.cavm@...il.com>
To:     David Miller <davem@...emloft.net>, arvind.yadav.cs@...il.com
Cc:     peter.chen@....com, fw@...len.de, david.daney@...ium.com,
        f.fainelli@...il.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return
 NULL error from devm_ioremap

On 12/19/2016 08:04 AM, David Miller wrote:
> From: Arvind Yadav <arvind.yadav.cs@...il.com>
> Date: Thu, 15 Dec 2016 00:33:30 +0530
>
>> Here, If devm_ioremap will fail. It will return NULL.
>> Kernel can run into a NULL-pointer dereference.
>> This error check will avoid NULL pointer dereference.
>>
>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@...il.com>
>
> Since ioremap() is in fact designed to possibly fail, we do
> need to always check it's return value.  So this change is
> correct and I have applied it to the 'net' tree.

Yes, I think that is fine, although I have not tested the patch.

In general I like to know if a patch fixes a problem that has occurred 
on a platform used by the patch author, or if the author just noticed an 
issue through code inspection or automated tool for a platform that they 
cannot test on.

This patch appears to fall into the second category, but attempts to 
determine this for sure were for the most part unsuccessful.

With respect to ioremap(), in general I agree that it is designed to 
possibly fail.  For mips64 however, I think the implementation can never 
fail.  Certainly testing for failure fits better with what we expect to 
see in Linux kernel code.


>
> Thanks.
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ