[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66bca69a-0036-4108-5963-002cce69376a@linux-m68k.org>
Date: Thu, 2 May 2024 10:47:21 +1000 (AEST)
From: Finn Thain <fthain@...ux-m68k.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>
cc: Kees Cook <keescook@...omium.org>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Erick Archer <erick.archer@...look.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 Wed, 1 May 2024, James Bottomley wrote:
> > The code itself is fine unless you have a 32-bit system with a
> > malicious card, so yeah, near zero risk.
>
> Well, no actually zero: we assume plugged in hardware to operate
> correctly (had this argument in the driver hardening thread a while
> ago), but in this particular case you'd have to have a card with a very
> high number of ports, which would cause kernel allocations to fail long
> before anything could introduce an overflow of sizeof(struct csio_lnode
> *) * hw->num_lns.
>
Then it should be safe to add an equivalent assertion. E.g.
BUG_ON(hw->num_lns > X) where X was derived either from knowledge of the
hardware or from some known-safe kalloc() limit. Though I wonder whether
BUG_ON() is the best way to encode preconditions for the benfit of static
checkers...
Powered by blists - more mailing lists