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 <[email protected]> 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().
...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
