[lkml]   [2003]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subjectdpt_i2o.c memleak/incorrectness

There is something strange going on in drivers/scsi/dpt_i2o.c in both
2.4 and 2.5. adpt_i2o_reset_hba() function allocates 4 bytes
for "status" stuff, then tries to reset controller, then
if timeout on first reset stage is reached, frees "status" and returns,
otherwise it proceeds to monitor "status" (which is modified by hardware
now, btw), and if timeout is reached, just exits.
On the first thought I just thought it is trivial memleak that can be
fixed with patch below, but after some more thining I just thought
"what if after some time controller awakes and modifies status,
but it is already allocated for other purposes", scary eh?
So may be we shold not free those four bytes on timeout at all just
for safeness reasons?

Found with help of smatch + enhanced unfree script.


===== drivers/scsi/dpt_i2o.c 1.9 vs edited =====
--- 1.9/drivers/scsi/dpt_i2o.c Wed Jan 8 18:26:13 2003
+++ edited/drivers/scsi/dpt_i2o.c Thu Mar 13 21:17:10 2003
@@ -1336,6 +1336,7 @@
printk(KERN_ERR "%s:Timeout waiting for IOP Reset.\n",pHba->name);
+ kfree(status);
return -ETIMEDOUT;
} while (m == EMPTY_QUEUE);
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at
 \ /
  Last update: 2005-03-22 13:33    [W:0.064 / U:2.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site