linux-kernel - Re: scsi: ses: Move a label in ses_enclosure_data

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]

Message-ID: <a35c6128d4449fec00238c909e5f6f45ebf4bcba.camel@linux.ibm.com>
Date: Sat, 30 Dec 2023 07:41:53 -0500
From: James Bottomley <jejb@...ux.ibm.com>
To: Markus Elfring <Markus.Elfring@....de>, linux-scsi@...r.kernel.org,
        kernel-janitors@...r.kernel.org,
        "Martin K. Petersen"
	 <martin.petersen@...cle.com>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: scsi: ses: Move a label in ses_enclosure_data_process()

On Sat, 2023-12-30 at 08:04 +0100, Markus Elfring wrote:
> > > The kfree() function was called in up to three cases by
> > > the ses_enclosure_data_process() function during error handling
> > > even if the passed variable contained a null pointer.
> > > This issue was detected by using the Coccinelle software.
> > 
> > Why is this an issue?  The whole point of having kfree(NULL) be a
> > nop
> 
> Such “a nop” can trigger the allocation of extra data processing
> resources, can't it?

No.

> > is so we don't have to special case the free path.
> 
> A bit more development attention can hopefully connect the mentioned
> label with a more appropriate jump target directly.

That's making the flow more complex as I pointed out in my initial
email.

> >                                                     The reason we
> > do that is because multiple special case paths through code leads
> > to more complex control flows and more potential bugs.
> 
> You probably know some advices from another information source.
> 
> https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consider+using+a+goto+chain+when+leaving+a+function+on+error+when+using+and+releasing+resources
> 

Yes, but it's about using staged deallocation at the end of the
function instead of in the if loops.  That's to *simplify* the exit
chain and make the error legs less error prone because the teardown
isn't repeated in if bodies.  It has no bearing on what you just tried
to do.

> >                                               If coccinelle
> > suddenly thinks this is a problem, it's coccinelle that needs
> > fixing.
> 
> This software tool can help to point source code places out for
> further considerations. The search patterns are evolving accordingly.

The pattern is wrong because kfree(NULL) exists as a teardown
simplification.

James