linux-kernel - Re: [PATCH] gpio: gpio-xilinx: Check return value of of_property_read

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, 28 Jun 2022 14:27:05 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Michal Simek <michal.simek@....com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Srinivas Neeli <srinivas.neeli@...inx.com>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Michal Simek <michal.simek@...inx.com>,
        neelisrinivas18@...il.com,
        Shubhrajyoti Datta <shubhrajyoti.datta@...inx.com>,
        srinivas.neeli@....com, Srinivas Goud <sgoud@...inx.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        git <git@...inx.com>
Subject: Re: [PATCH] gpio: gpio-xilinx: Check return value of of_property_read_u32

On Mon, Jun 20, 2022 at 8:26 AM Michal Simek <michal.simek@....com> wrote:
> On 6/17/22 18:02, Andy Shevchenko wrote:
> > On Fri, Jun 17, 2022 at 7:20 AM Srinivas Neeli
> > <srinivas.neeli@...inx.com> wrote:
> >>
> >> In five different instances the return value of "of_property_read_u32"
> >> API was neither captured nor checked.
> >>
> >> Fixed it by capturing the return value and then checking for any error.
> >>
> >> Signed-off-by: Srinivas Neeli <srinivas.neeli@...inx.com>
> >> Addresses-Coverity: "check_return"
> >
> > I think the best course of action here is to go and fix Coverity while
> > marking these as false positives.
> >
> > To the idea of castings -- this is not good style and (many?)
> > maintainers in kernel do not accept such "workaround" for fixing
> > broken tool.
>
> Let's wait for Linus what he will say about it.
> I can't see nothing wrong about declaring that I am intentionally ignoring
> return code.

I don't think this patch should be applied.

The problem with static analysis is that such tools have no feeling
for context at all, and in this case the context makes it pretty
clear why it is safe to ignore these return values.

But we need to adopt the tool to the code not adopt the code to
the tool.

Yours,
Linus Walleij