From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 12 Jul 2026 15:45:19 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “faux_device_destroy”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “dev” behind a condition check.

This issue was detected by using the Coccinelle software.

Fixes: 35fa2d88ca9481e5caf533d58b99ca259c63b2fe ("driver core: add a faux bus for use when a simple device/bus is needed")
Cc: stable@vger.kernel.org
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/base/faux.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/faux.c b/drivers/base/faux.c
index a8329f88222e..4eb22d082552 100644
--- a/drivers/base/faux.c
+++ b/drivers/base/faux.c
@@ -221,11 +221,12 @@ EXPORT_SYMBOL_GPL(faux_device_create);
  */
 void faux_device_destroy(struct faux_device *faux_dev)
 {
-	struct device *dev = &faux_dev->dev;
+	struct device *dev;
 
 	if (!faux_dev)
 		return;
 
+	dev = &faux_dev->dev;
 	device_del(dev);
 
 	/* The final put_device() will clean up the memory we allocated for this device. */
-- 
2.55.0

On Sun, Jul 12, 2026 at 03:56:09PM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 12 Jul 2026 15:45:19 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “faux_device_destroy”.
> 
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “dev” behind a condition check.

There is no such "undefined behavior" here, sorry, please fix your
tools.

>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “faux_device_destroy”.
>>
>> Thus avoid the risk for undefined behaviour by moving the assignment
>> for the variable “dev” behind a condition check.
> 
> There is no such "undefined behavior" here, sorry, please fix your tools.

Please take another look at related information sources.

EXP34-C: Do not dereference null pointers
https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/


See also:
https://lore.kernel.org/kernel-janitors/d7a8e34b-e490-47fc-b892-886e1c799c4f@web.de/
https://lkml.org/lkml/2026/7/2/2241

Regards,
Markus

On Sun, Jul 12, 2026 at 06:23:47PM +0200, Markus Elfring wrote:
> >> The address of a data structure member was determined before
> >> a corresponding null pointer check in the implementation of
> >> the function “faux_device_destroy”.
> >>
> >> Thus avoid the risk for undefined behaviour by moving the assignment
> >> for the variable “dev” behind a condition check.
> > 
> > There is no such "undefined behavior" here, sorry, please fix your tools.
> 
> Please take another look at related information sources.
> 
> EXP34-C: Do not dereference null pointers
> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
> 
> 
> See also:
> https://lore.kernel.org/kernel-janitors/d7a8e34b-e490-47fc-b892-886e1c799c4f@web.de/
> https://lkml.org/lkml/2026/7/2/2241

Please see the places in the past where I have rejected this very patch.
Nothing has changed since then.

thanks,

greg k-h

…
>> Please take another look at related information sources.
>>
>> EXP34-C: Do not dereference null pointers
>> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
>>
>>
>> See also:
>> https://lore.kernel.org/kernel-janitors/d7a8e34b-e490-47fc-b892-886e1c799c4f@web.de/
>> https://lkml.org/lkml/2026/7/2/2241
> 
> Please see the places in the past where I have rejected this very patch.
> Nothing has changed since then.
Can involved special development views be resolved better by applying scope-based resource management
for the affected function implementation?

Regards,
Markus

On Sun, Jul 12, 2026 at 06:54:13PM +0200, Markus Elfring wrote:
> …
> >> Please take another look at related information sources.
> >>
> >> EXP34-C: Do not dereference null pointers
> >> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
> >>
> >>
> >> See also:
> >> https://lore.kernel.org/kernel-janitors/d7a8e34b-e490-47fc-b892-886e1c799c4f@web.de/
> >> https://lkml.org/lkml/2026/7/2/2241
> > 
> > Please see the places in the past where I have rejected this very patch.
> > Nothing has changed since then.
> Can involved special development views be resolved better by applying scope-based resource management
> for the affected function implementation?

*plonk*