[PATCH] 2.6.9-rc1 drivers/scsi/libata-core.c

[PATCH] 2.6.9-rc1 drivers/scsi/libata-core.c

[Jeremy Higdon]

We seem to have found an overflow problem in libata-core.c.
We were trying to DMA to the address range 0xffff8000-0xffffbfff.

In the original version of the code, given that address and
count (0xffff8000 and 0x4000), the variable "boundary" would be
set to 0, causing len to be set to 0x8000 (which is greater than
sg_len).  Then at the bottom of the loop, sg_len would be set
to 0xffffc000 (0x4000 - 0x8000), which would then cause the
loop never to terminate (until much of memory was scribbled
over or the kernel died).

The code below should be functionally identical, but not be
subject to the same overflow problem (boundary needs to be a
u33).

Signed-off-by: jeremy@sgi.com

===== drivers/scsi/libata-core.c 1.94 vs edited =====
--- 1.94/drivers/scsi/libata-core.c	2004-08-15 23:35:24 -07:00
+++ edited/drivers/scsi/libata-core.c	2004-08-25 21:10:45 -07:00
@@ -1836,7 +1836,7 @@
 
 	idx = 0;
 	for (nelem = qc->n_elem; nelem; nelem--,sg++) {
-		u32 addr, boundary;
+		u32 addr, offset;
 		u32 sg_len, len;
 
 		/* determine if physical DMA addr spans 64K boundary.
@@ -1847,10 +1847,10 @@
 		sg_len = sg_dma_len(sg);
 
 		while (sg_len) {
-			boundary = (addr & ~0xffff) + (0xffff + 1);
+			offset = addr & 0xffff;
 			len = sg_len;
-			if ((addr + sg_len) > boundary)
-				len = boundary - addr;
+			if ((offset + sg_len) > 0x10000)
+				len = 0x10000 - offset;
 
 			ap->prd[idx].addr = cpu_to_le32(addr);
 			ap->prd[idx].flags_len = cpu_to_le32(len & 0xffff);

Re: [PATCH] 2.6.9-rc1 drivers/scsi/libata-core.c

[Jeff Garzik]

applied, but with a comment:

please use a descriptive subject.  Standard patch-applying scripts we 
all use take the email subject line as the one-line short description of 
your change.  Obviously "2.6.9-rc1  drivers/scsi/libata-core.c" doesn't 
tell us anything about the change itself.

	Jeff