aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/scsi/mvme16x.c
diff options
context:
space:
mode:
authorJesper Juhl <jesper.juhl@gmail.com>2006-05-13 18:39:38 -0400
committerJames Bottomley <jejb@mulgrave.il.steeleye.com>2006-05-20 10:23:23 -0400
commit07fb75a50600c0c480b40c6d11dbc993f21bc2bc (patch)
tree9012c689500d33f576c99f00235f44901c86a6cc /drivers/scsi/mvme16x.c
parent5b9851b5511833a96fea2196971b5709ef019136 (diff)
[SCSI] fix (unlikely) memory leak in DAC960 driver
The Coverity checker found a memory leak (bug nr. 1245) in drivers/block/DAC960.c::DAC960_V2_ProcessCompletedCommand() The leak is pretty unlikely since it requires that the first of two successive kmalloc() calls fail while the second one succeeds. But it can still happen even if it's unlikely. If the first call that allocates 'PhysicalDeviceInfo' fails but the one that allocates 'InquiryUnitSerialNumber' succeeds, then we will leak the memory allocated to 'InquiryUnitSerialNumber' when the variable goes out of scope. A simple fix for this is to change the existing code that frees 'PhysicalDeviceInfo' if that one was allocated but 'InquiryUnitSerialNumber' was not, into a check for either pointer being NULL and if so just free both. This is safe since kfree() can deal with being passed a NULL pointer and it avoids the leak. While I was there I also removed the casts of the kmalloc() return value since it's pointless. I also updated the driver version since this patch changes the workings of the code (however slightly). This issue could probably be fixed a lot more elegantly, but the code is a big mess IMHO and I just took the least intrusive route to a fix that I could find instead of starting on a cleanup as well (that can come later). Please consider for inclusion. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Diffstat (limited to 'drivers/scsi/mvme16x.c')
0 files changed, 0 insertions, 0 deletions