linux-kernel - Re: [PATCH v5] checkpatch: add uninitialized pointer with _

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: <4a277387-ca59-4688-bf7b-13da62589fcd@kernel.org>
Date: Mon, 24 Nov 2025 15:52:05 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Ally Heev <allyheev@...il.com>, Dwaipayan Ray <dwaipayanray1@...il.com>,
 Lukas Bulwahn <lukas.bulwahn@...il.com>, Joe Perches <joe@...ches.com>,
 Jonathan Corbet <corbet@....net>, Andy Whitcroft <apw@...onical.com>
Cc: workflows@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, Dan Carpenter <dan.carpenter@...aro.org>,
 David Hunter <david.hunter.linux@...il.com>,
 Shuah Khan <skhan@...uxfoundation.org>, Viresh Kumar <vireshk@...nel.org>,
 Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
 linux-pm <linux-pm@...r.kernel.org>, dan.j.williams@...el.com,
 Geert Uytterhoeven <geert@...ux-m68k.org>,
 James Bottomley <James.Bottomley@...senpartnership.com>
Subject: Re: [PATCH v5] checkpatch: add uninitialized pointer with __free
 attribute check

On 24/11/2025 15:44, Ally Heev wrote:
> uninitialized pointers with __free attribute can cause undefined
> behavior as the memory randomly assigned to the pointer is freed
> automatically when the pointer goes out of scope.
> add check in checkpatch to detect such issues.
> 
> Suggested-by: Dan Carpenter <dan.carpenter@...aro.org>
> Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
> Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
> Acked-by: Dan Williams <dan.j.williams@...el.com>
> Signed-off-by: Ally Heev <allyheev@...il.com>
> ---
> Testing:
> ran checkpatch.pl before and after the change on 
> crypto/asymmetric_keys/x509_public_key.c, which has
> both initialized with NULL and uninitialized pointers
> ---
> Changes in v5:
> - fixed checkpatch doc
> - Link to v4: https://lore.kernel.org/r/20251107-aheev-checkpatch-uninitialized-free-v4-1-4822a6ac728f@gmail.com
> 
> Changes in v4:
> - fixed UNINITIALIZED_PTR_WITH_FREE description 
> - Link to v3: https://lore.kernel.org/r/20251025-aheev-checkpatch-uninitialized-free-v3-1-a67f72b1c2bd@gmail.com
> 
> Changes in v3:
> - remove $FreeAttribute
> - Link to v2: https://lore.kernel.org/r/20251024-aheev-checkpatch-uninitialized-free-v2-0-16c0900e8130@gmail.com
> 
> Changes in v2:
> - change cover letter and title to reflect new changes
> - fix regex to handle multiple declarations in a single line case
> - convert WARN to ERROR for uninitialized pointers
> - add a new WARN for pointers initialized with NULL 
> - NOTE: tried handling multiple declarations on a single line by splitting
>         them and matching the parts with regex, but, it turned out to be 
> 	complex and overkill. Moreover, multi-line declarations pose a threat
> - Link to v1: https://lore.kernel.org/r/20251021-aheev-checkpatch-uninitialized-free-v1-1-18fb01bc6a7a@gmail.com
> ---
>  Documentation/dev-tools/checkpatch.rst | 20 ++++++++++++++++++++
>  scripts/checkpatch.pl                  |  6 ++++++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
> index d5c47e560324fb2399a5b1bc99c891ed1de10535..865aaaf6dc51b1c3f763b3cbb8713da3d00db960 100644
> --- a/Documentation/dev-tools/checkpatch.rst
> +++ b/Documentation/dev-tools/checkpatch.rst
> @@ -1009,6 +1009,26 @@ Functions and Variables
>  
>        return bar;
>  
> +  **UNINITIALIZED_PTR_WITH_FREE**
> +    Pointers with __free attribute should be defined and assigned in one

You did not implement my proposal fully. I wanted to express that their
declaration should be in the place of use, meaning first use.

> +    statement. In this case declarations at the top of the function rule

This does not solve it, because one can declare, define and assign in
top part of the function not achieving what we want - place of use.

Not sure if it is worth debating on, so overall (although I did not
verify regex very thoroughly):

Reviewed-by: Krzysztof Kozlowski <krzk@...nel.org>

Best regards,
Krzysztof