Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=07da60c1f45a6a5f563429e88e8c94c82f9132eb
Commit:     07da60c1f45a6a5f563429e88e8c94c82f9132eb
Parent:     802ae2f05b646c1e5f9e33cfe4c80cfa1452a0e3
Author:     Anton Blanchard <[EMAIL PROTECTED]>
AuthorDate: Wed Mar 21 08:41:47 2007 -0500
Committer:  James Bottomley <[EMAIL PROTECTED]>
CommitDate: Sun Apr 1 10:02:00 2007 -0500

    [SCSI] lpfc: fix oops when parsing dodgy VPD
    
    We have seen two cases where VPD on an emulex card has been incorrect
    and we end up walking off the end of memory. It looks like someone made
    an update (increased the length of a string) without increasing the
    Length field. Then we do:
    
        Length -= (3+i);
    
    And since Length is unsigned it becomes very large and we loop forever
    in the encapsulating:
    
        while (Length > 0) {
    
    If we make Length signed then we fall out of the loop and proceed on.
    
    Its important to note we have only seen this in the lab and it may be
    the only two cases of this in existence, but since the rest of the code
    has been written to be resilient against bad VPD we may as well fix this
    too.
    
    Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>
    Acked-by: James Smart <[EMAIL PROTECTED]>
    Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
 drivers/scsi/lpfc/lpfc_init.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 9d014e5..09a9c8a 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -671,7 +671,7 @@ static int
 lpfc_parse_vpd(struct lpfc_hba * phba, uint8_t * vpd, int len)
 {
        uint8_t lenlo, lenhi;
-       uint32_t Length;
+       int Length;
        int i, j;
        int finished = 0;
        int index = 0;
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to