linux-kernel - Re: [PATCH] scsi: fix uninitialized pointers with free attr

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

Message-ID: <aRyBI_j77mQaQxgT@stanley.mountain>
Date: Tue, 18 Nov 2025 17:22:27 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Ally Heev <allyheev@...il.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scsi: fix uninitialized pointers with free attr

On Tue, Nov 18, 2025 at 08:21:16AM -0500, James Bottomley wrote:
> On Tue, 2025-11-18 at 09:17 +0300, Dan Carpenter wrote:
> > On Thu, Nov 06, 2025 at 11:06:29AM -0500, James Bottomley wrote:
> [...]
> > > However, why would we treat a __free variable any differently from
> > > one without the annotation?  The only difference is that a function
> > > gets called on it before exit, but as long as something can detect
> > > calling this on uninitialized variables their properties are
> > > definitely no different from non-__free variables so the can be
> > > treated exactly the same.
> > > 
> > > To revisit why we do this for non-__free variables: most people
> > > (although there are definitely languages where this isn't true and
> > > people who think we should follow this) think that having variables
> > > at the top of a function (or at least top of a code block) make the
> > > code easier to understand.  Additionally, keeping the variable
> > > uninitialized allows the compiler to detect any use before set
> > > scenarios, which can be somewhat helpful detecting code faults (I'm
> > > less persuaded by this, particularly given the number of false
> > > positive warnings we've seen that force us to add annotations,
> > > although this seems to be getting better).
> > > 
> > > So either we throw out the above for everything ... which I really
> > > wouldn't want, or we enforce it for *all* variables.
> > > 
> > 
> > Yeah.  You make a good point...
> > 
> > On the other hand, a bunch of maintainers are convinced that every
> > free variable should be initialized to a valid value at declaration
> > time and will reject patches which don't do that.
> 
> Which maintainers?

Here is an example where Krzysztof says "This is not recommended way of
using cleanup. You should declare it with constructor."
https://lore.kernel.org/all/a2fc02e2-d75a-43ed-8057-9b3860873ebb@kernel.org/

I know there are other people who feel this way as well but I can't
recall who.  It's in the documentation in include/linux/cleanup.h

 * Given that the "__free(...) = NULL" pattern for variables defined at
 * the top of the function poses this potential interdependency problem
 * the recommendation is to always define and assign variables in one
 * statement and not group variable definitions at the top of the
 * function when __free() is used.

regards,
dan carpenter