linux-hardening - Re: [PATCH v3] scsi: csiostor: Use kcalloc() instead of kzalloc()

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <070eccee-25c1-05ae-0ae8-7c6fe2eff82f@linux-m68k.org>
Date: Tue, 30 Apr 2024 11:54:27 +1000 (AEST)
From: Finn Thain <fthain@...ux-m68k.org>
To: Kees Cook <keescook@...omium.org>
cc: "Martin K. Petersen" <martin.petersen@...cle.com>, 
    Erick Archer <erick.archer@...look.com>, 
    "James E.J. Bottomley" <jejb@...ux.ibm.com>, 
    Bjorn Helgaas <bhelgaas@...gle.com>, Justin Stitt <justinstitt@...gle.com>, 
    "Gustavo A. R. Silva" <gustavoars@...nel.org>, linux-scsi@...r.kernel.org, 
    linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v3] scsi: csiostor: Use kcalloc() instead of kzalloc()

On Mon, 29 Apr 2024, Kees Cook wrote:

> this isn't a case where we can show identical binary output, since this 
> actively adds overflow checking via kcalloc() internals.
> 
> ...
> 
> it is a trivially correct change that uses a more robust API and more 
> idiomatic allocation sizeof()s

If a change is "trivially correct" then the proof is trivial too.

Based only on what you wrote above, omitting the overflow check would give 
binary equivalence. That validates the driver change (for hardware you 
lack).

But, since a build without the overflow check must contain a second 
change, you must validate that change too by showing that kcalloc() 
internals still work for every other caller. (You do this using hardware 
you have.)