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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 18 Feb 2019 22:40:32 +0100 From: Markus Elfring <Markus.Elfring@....de> To: Wen Yang <wen.yang99@....com.cn>, Julia Lawall <julia.lawall@...6.fr> Cc: Wen Yang <yellowriver2010@...mail.com>, Gilles Muller <Gilles.Muller@...6.fr>, Nicolas Palix <nicolas.palix@...g.fr>, Michal Marek <michal.lkml@...kovi.net>, Masahiro Yamada <yamada.masahiro@...ionext.com>, Cheng Shengyu <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() >> 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. Would you like to clarify the circumstances a bit more under which you would notice corresponding differences? > When != e = id achieves this behavior. I try another explanation approach for a potentially safer source code search. 1. If you would look at the following SmPL code lines again, I imagine that you can determine also an useful constraint for this place. … + id = of_find_device_by_node@p1(x) + ... when != ?????? = ?????? + if (!id || ...) { ... return ...; } … 2. Petr Strnad expressed the need for another constraint in the commit “scripts: Coccinelle script for pci_free_consistent()” (from 2013-05-08). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/free/pci_free_consistent.cocci?id=f7b167113753e95ae61383e234f8d10142782ace#n12 I find that there are additional software development challenges to consider around another desirable assignment exclusion from the place of the return value storage and the data processing possibilities behind the corresponding null pointer check. The previous approach worked with the metavariables types (or kinds) “expression” and “local idexpression id” to some degree so far. But it is expected that an undesirable missed reference release can be safely pointed out only if the received platform device pointer is used only within a found function implementation. I would interpret this data flow requirement in the way that the pointer should not be forwarded to a data structure with a scope from outside (global?) the found function implementation. How would you like to express such an aspect by the current (or future) means of the semantic patch language? Regards, Markus
Powered by blists - more mailing lists