public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	linux-scsi@vger.kernel.org, mpi3mr-linuxdrv.pdl@broadcom.com
Cc: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>,
	Kashyap Desai <kashyap.desai@broadcom.com>,
	Sumit Saxena <sumit.saxena@broadcom.com>,
	Sreekanth Reddy <sreekanth.reddy@broadcom.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH 2/3] scsi: mpi3mr: fix bitmap memory size calculation
Date: Mon, 12 Dec 2022 14:46:15 +0900	[thread overview]
Message-ID: <d16ef645-d60c-6b2f-7369-5b7f535631ca@opensource.wdc.com> (raw)
In-Reply-To: <c65beb54-7ff3-1a95-f255-916c25ef03d3@opensource.wdc.com>

On 12/12/22 14:35, Damien Le Moal wrote:
> On 12/12/22 10:57, Shin'ichiro Kawasaki wrote:
>> To allocate memory for bitmaps, the mpi3mr driver calculates sizes of
>> each bitmap using byte as unit. However, bit operation helper functions
>> assume that bitmaps are allocated using unsigned long as unit. This gap
>> causes memory access beyond the bitmap memory size and results in "BUG:
>> KASAN: slab-out-of-bounds". The BUG was observed at firmware download to
>> eHBA-9600. Call trace indicated that the out-of-bounds access happened
>> in find_first_zero_bit called from mpi3mr_send_event_ack for the bitmap
>> miroc->evtack_cmds_bitmap.
>>
>> To avoid the BUG, fix bitmap size calculations using unsigned long as
>> unit. Apply this fix to five places to cover all bitmap size
>> calculations in the driver.
>>
>> Fixes: c5758fc72b92 ("scsi: mpi3mr: Gracefully handle online FW update operation")
>> Fixes: e844adb1fbdc ("scsi: mpi3mr: Implement SCSI error handler hooks")
>> Fixes: c1af985d27da ("scsi: mpi3mr: Add Event acknowledgment logic")
>> Fixes: 824a156633df ("scsi: mpi3mr: Base driver code")
>> Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
>> ---
>>  drivers/scsi/mpi3mr/mpi3mr_fw.c | 25 ++++++++++---------------
>>  1 file changed, 10 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/scsi/mpi3mr/mpi3mr_fw.c b/drivers/scsi/mpi3mr/mpi3mr_fw.c
>> index 0c4aabaefdcc..272c318387b7 100644
>> --- a/drivers/scsi/mpi3mr/mpi3mr_fw.c
>> +++ b/drivers/scsi/mpi3mr/mpi3mr_fw.c
>> @@ -1160,9 +1160,8 @@ mpi3mr_revalidate_factsdata(struct mpi3mr_ioc *mrioc)
>>  		    "\tcontroller while sas transport support is enabled at the\n"
>>  		    "\tdriver, please reboot the system or reload the driver\n");
>>  
>> -	dev_handle_bitmap_sz = mrioc->facts.max_devhandle / 8;
>> -	if (mrioc->facts.max_devhandle % 8)
>> -		dev_handle_bitmap_sz++;
>> +	dev_handle_bitmap_sz = sizeof(unsigned long) *
>> +		DIV_ROUND_UP(mrioc->facts.max_devhandle, BITS_PER_LONG);
>>  	if (dev_handle_bitmap_sz > mrioc->dev_handle_bitmap_sz) {
>>  		removepend_bitmap = krealloc(mrioc->removepend_bitmap,
>>  		    dev_handle_bitmap_sz, GFP_KERNEL);
>> @@ -2957,25 +2956,22 @@ static int mpi3mr_alloc_reply_sense_bufs(struct mpi3mr_ioc *mrioc)
>>  	if (!mrioc->pel_abort_cmd.reply)
>>  		goto out_failed;
>>  
>> -	mrioc->dev_handle_bitmap_sz = mrioc->facts.max_devhandle / 8;
>> -	if (mrioc->facts.max_devhandle % 8)
>> -		mrioc->dev_handle_bitmap_sz++;
> 
> mrioc->dev_handle_bitmap_sz = (mrioc->facts.max_devhandle + 7) >> 3;
> 
> would be a lot simpler...

Actually, if the code is changed to use bitmap_zalloc(), no rounding up to
8 or BITS_PER_LONG is needed at all, so the code would be really simpler.

> 
>> +	mrioc->dev_handle_bitmap_sz = sizeof(unsigned long) *
>> +		DIV_ROUND_UP(mrioc->facts.max_devhandle, BITS_PER_LONG);
>>  	mrioc->removepend_bitmap = kzalloc(mrioc->dev_handle_bitmap_sz,
>>  	    GFP_KERNEL);
> 
> What about using bitmap_alloc() here and keep the dev_handle_bitmap_sz
> value as is ?
> 
> (same for the other bitmaps)
> 
>>  	if (!mrioc->removepend_bitmap)
>>  		goto out_failed;
>>  
>> -	mrioc->devrem_bitmap_sz = MPI3MR_NUM_DEVRMCMD / 8;
>> -	if (MPI3MR_NUM_DEVRMCMD % 8)
>> -		mrioc->devrem_bitmap_sz++;
>> +	mrioc->devrem_bitmap_sz = sizeof(unsigned long) *
>> +		DIV_ROUND_UP(MPI3MR_NUM_DEVRMCMD, BITS_PER_LONG);
>>  	mrioc->devrem_bitmap = kzalloc(mrioc->devrem_bitmap_sz,
>>  	    GFP_KERNEL);
>>  	if (!mrioc->devrem_bitmap)
>>  		goto out_failed;
>>  
>> -	mrioc->evtack_cmds_bitmap_sz = MPI3MR_NUM_EVTACKCMD / 8;
>> -	if (MPI3MR_NUM_EVTACKCMD % 8)
>> -		mrioc->evtack_cmds_bitmap_sz++;
>> +	mrioc->evtack_cmds_bitmap_sz = sizeof(unsigned long) *
>> +		DIV_ROUND_UP(MPI3MR_NUM_EVTACKCMD, BITS_PER_LONG);
>>  	mrioc->evtack_cmds_bitmap = kzalloc(mrioc->evtack_cmds_bitmap_sz,
>>  	    GFP_KERNEL);
>>  	if (!mrioc->evtack_cmds_bitmap)
>> @@ -3415,9 +3411,8 @@ static int mpi3mr_alloc_chain_bufs(struct mpi3mr_ioc *mrioc)
>>  		if (!mrioc->chain_sgl_list[i].addr)
>>  			goto out_failed;
>>  	}
>> -	mrioc->chain_bitmap_sz = num_chains / 8;
>> -	if (num_chains % 8)
>> -		mrioc->chain_bitmap_sz++;
>> +	mrioc->chain_bitmap_sz = sizeof(unsigned long) *
>> +		DIV_ROUND_UP(num_chains, BITS_PER_LONG);
>>  	mrioc->chain_bitmap = kzalloc(mrioc->chain_bitmap_sz, GFP_KERNEL);
>>  	if (!mrioc->chain_bitmap)
>>  		goto out_failed;
> 

-- 
Damien Le Moal
Western Digital Research


  reply	other threads:[~2022-12-12  5:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-12  1:57 [PATCH 0/3] scsi: mpi3mr: fix issues found by KASAN Shin'ichiro Kawasaki
2022-12-12  1:57 ` [PATCH 1/3] scsi: mpi3mr: fix alltgt_info copy size in mpi3mr_get_all_tgt_info Shin'ichiro Kawasaki
2022-12-12  5:27   ` Damien Le Moal
2022-12-12 12:01     ` Shinichiro Kawasaki
2022-12-12  1:57 ` [PATCH 2/3] scsi: mpi3mr: fix bitmap memory size calculation Shin'ichiro Kawasaki
2022-12-12  5:35   ` Damien Le Moal
2022-12-12  5:46     ` Damien Le Moal [this message]
2022-12-12 12:15       ` Shinichiro Kawasaki
2022-12-12  1:57 ` [PATCH 3/3] scsi: mpi3mr: fix missing mrioc->evtack_cmds initialization Shin'ichiro Kawasaki
2022-12-12  5:36   ` Damien Le Moal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d16ef645-d60c-6b2f-7369-5b7f535631ca@opensource.wdc.com \
    --to=damien.lemoal@opensource.wdc.com \
    --cc=kashyap.desai@broadcom.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mpi3mr-linuxdrv.pdl@broadcom.com \
    --cc=sathya.prakash@broadcom.com \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=sreekanth.reddy@broadcom.com \
    --cc=sumit.saxena@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox