[PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[Jesper Juhl]

(previously send on 09-Aug-2007 20:47)

Hi,

The Coverity checker noticed that we may overrun a statically allocated 
array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find().

The case is this; In 'struct lpfc_hba' we have 

	#define LPFC_MAX_HBQS  4
	...
	struct lpfc_hba {
		...
		struct hbq_s hbqs[LPFC_MAX_HBQS];
		...
	};

But then in lpfc_sli_hbqbuf_find() we have this code 

	hbqno = tag >> 16;
	if (hbqno > LPFC_MAX_HBQS)
		return NULL;

if 'hbqno' ends up as exactely 4, then we won't return, and then this

	list_for_each_entry(d_buf, &phba->hbqs[hbqno].hbq_buffer_list, list) {

will cause an overflow of the statically allocated array at index 4, 
since the valid indices are only 0-3. 

I propose this patch, that simply changes the 'hbqno > LPFC_MAX_HBQS' 
into 'hbqno >= LPFC_MAX_HBQS' as a possible fix.


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Acked-by: James Smart <james.smart@emulex.com>
---

 drivers/scsi/lpfc/lpfc_sli.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index ce5ff2b..e5337ad 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -675,7 +675,7 @@ lpfc_sli_hbqbuf_find(struct lpfc_hba *phba, uint32_t tag)
 	uint32_t hbqno;
 
 	hbqno = tag >> 16;
-	if (hbqno > LPFC_MAX_HBQS)
+	if (hbqno >= LPFC_MAX_HBQS)
 		return NULL;
 
 	list_for_each_entry(d_buf, &phba->hbqs[hbqno].hbq_buffer_list, list) {

Re: [PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[James Smart]

NACK

The fix is contained in our 8.2.2 sources recently posted and pushed by James
as part of his last scsi fixes.

-- james s

Jesper Juhl wrote:
> (previously send on 09-Aug-2007 20:47)
> 
> Hi,
> 
> The Coverity checker noticed that we may overrun a statically allocated 
> array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find().
> 
> The case is this; In 'struct lpfc_hba' we have 
> 
> 	#define LPFC_MAX_HBQS  4
> 	...
> 	struct lpfc_hba {
> 		...
> 		struct hbq_s hbqs[LPFC_MAX_HBQS];
> 		...
> 	};
> 
> But then in lpfc_sli_hbqbuf_find() we have this code 
> 
> 	hbqno = tag >> 16;
> 	if (hbqno > LPFC_MAX_HBQS)
> 		return NULL;
> 
> if 'hbqno' ends up as exactely 4, then we won't return, and then this
> 
> 	list_for_each_entry(d_buf, &phba->hbqs[hbqno].hbq_buffer_list, list) {
> 
> will cause an overflow of the statically allocated array at index 4, 
> since the valid indices are only 0-3. 
> 
> I propose this patch, that simply changes the 'hbqno > LPFC_MAX_HBQS' 
> into 'hbqno >= LPFC_MAX_HBQS' as a possible fix.
> 
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Acked-by: James Smart <james.smart@emulex.com>
> ---
> 
>  drivers/scsi/lpfc/lpfc_sli.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
> index ce5ff2b..e5337ad 100644
> --- a/drivers/scsi/lpfc/lpfc_sli.c
> +++ b/drivers/scsi/lpfc/lpfc_sli.c
> @@ -675,7 +675,7 @@ lpfc_sli_hbqbuf_find(struct lpfc_hba *phba, uint32_t tag)
>  	uint32_t hbqno;
>  
>  	hbqno = tag >> 16;
> -	if (hbqno > LPFC_MAX_HBQS)
> +	if (hbqno >= LPFC_MAX_HBQS)
>  		return NULL;
>  
>  	list_for_each_entry(d_buf, &phba->hbqs[hbqno].hbq_buffer_list, list) {
> 
> 
> 
> 

Re: [PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[Jesper Juhl]

On 13/08/07, James Smart <James.Smart@emulex.com> wrote:
> NACK
>
> The fix is contained in our 8.2.2 sources recently posted and pushed by James
> as part of his last scsi fixes.
>

I actually did look for it, but couldn't find any lpfc commits with me
listed as author, so I assumed it had not been merged.
I just looked again, at the source this time, up-to-date mainline git
tree, and I still see

        hbqno = tag >> 16;
        if (hbqno > LPFC_MAX_HBQS)
                return NULL;

in drivers/scsi/lpfc/lpfc_sli.c

???


> -- james s
>
> Jesper Juhl wrote:
> > (previously send on 09-Aug-2007 20:47)
> >
> > Hi,
> >
> > The Coverity checker noticed that we may overrun a statically allocated
> > array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find().
...

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[James Smart]

Ok.... here's what happened,

- We changed the define so that it matched what we are using. We never configure
   more than 4 HBQ, thus the index will never be beyond 0-3. The if-check is actually
   innoculous. Given that the change wasn't your patch, we didn't include you as
   the author.

- Coding-wise, you are right, we still didn't fix the range check.

Since this really is just something to keep the tools happy - I'll recind the NACK.
I'll worry about simply removing this if-check later...

James/Andrew, accept this patch - ACK.

-- james s

Jesper Juhl wrote:
> On 13/08/07, James Smart <James.Smart@emulex.com> wrote:
>> NACK
>>
>> The fix is contained in our 8.2.2 sources recently posted and pushed by James
>> as part of his last scsi fixes.
>>
> 
> I actually did look for it, but couldn't find any lpfc commits with me
> listed as author, so I assumed it had not been merged.
> I just looked again, at the source this time, up-to-date mainline git
> tree, and I still see
> 
>         hbqno = tag >> 16;
>         if (hbqno > LPFC_MAX_HBQS)
>                 return NULL;
> 
> in drivers/scsi/lpfc/lpfc_sli.c
> 
> ???
> 
> 
>> -- james s
>>
>> Jesper Juhl wrote:
>>> (previously send on 09-Aug-2007 20:47)
>>>
>>> Hi,
>>>
>>> The Coverity checker noticed that we may overrun a statically allocated
>>> array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find().
> ...
> 

Re: [PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array

[Jesper Juhl]

On 13/08/07, James Smart <James.Smart@emulex.com> wrote:
> Ok.... here's what happened,
>
> - We changed the define so that it matched what we are using. We never configure
>    more than 4 HBQ, thus the index will never be beyond 0-3. The if-check is actually
>    innoculous. Given that the change wasn't your patch, we didn't include you as
>    the author.
>
And that's not a problem. I only mentioned it to explain how I
searched for the patch before I resend it.

> - Coding-wise, you are right, we still didn't fix the range check.
>
> Since this really is just something to keep the tools happy - I'll recind the NACK.
> I'll worry about simply removing this if-check later...
>
> James/Andrew, accept this patch - ACK.
>


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html