2.6.9-rc1 drivers/scsi/libata-core.c

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).

===== drivers/scsi/libata-core.c 1.94 vs edited =====

@@ -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);

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