linux-kernel - Re: [v6] coccinelle: semantic code search for missing put

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-next>] [day] [month] [year] [list]

Date:   Mon, 18 Feb 2019 07:43:26 +0100 (CET)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     wen.yang99@....com.cn
cc:     Markus.Elfring@....de, yellowriver2010@...mail.com,
        Gilles Muller <Gilles.Muller@...6.fr>, nicolas.palix@...g.fr,
        michal.lkml@...kovi.net, yamada.masahiro@...ionext.com,
        cheng.shengyu@....com.cn, kernel-janitors@...r.kernel.org,
        linux-kernel@...r.kernel.org, cocci@...teme.lip6.fr
Subject: Re: [v6] coccinelle: semantic code search for missing put_device()



On Mon, 18 Feb 2019, wen.yang99@....com.cn wrote:

> > > when != e = id achieves this behavior.
> >
> > I can not agree to this view completely because of the meaning that is connected
> > with these variable identifiers.
> >
> > Both metavariables share the kind “expression”. So I can imagine
> > that there is an intersection for the source code match possibility.
> > But one was intentionally restricted to the kind “local idexpression” so far.
> >
> > Which data element should not get reassigned here (before a corresponding
> > null pointer check)?
> >
>
> Thank you for your comments.
> We did some experiments:
> +id = of_find_device_by_node@p1(x)
> +... when != e = id
> ...
> Or:
> ...
> + ... when != id = e
>
> The number of issuses found by these two methods is the same.
> When != e = id achieves this behavior.

They are the same because neither issue arises.  I would have a hard time
saying which one is more reasonable to test, since both are extremely
unlikely.

julia


>
> In addition, we feel that we should probably accept this patch first, use it to find more memory leaks, and solve the actual problems in the kernel code.
> As for the patch itself, we can continue to pursue perfect in the process of using it to solve practical problems.
>
> Regards,
> Wen