https://bugzilla.kernel.org/show_bug.cgi?id=32362 Summary: ATA Passthrough generates incorrect LBA addresses with OS ASYNC activity, Image of Bus-trace attached Product: SCSI Drivers Version: 2.5 Kernel Version: All Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Other AssignedTo: scsi_drivers-other@xxxxxxxxxxxxxxxxxxxx ReportedBy: marcus.firthview@xxxxxxxxx Regression: No Created an attachment (id=52792) --> (https://bugzilla.kernel.org/attachment.cgi?id=52792) Finisar Bus-Trace of SG tools w/System Activity Bug: Low 28 bits of LBA address to drive after DMA completion (read/write), following the interrupt to the kernel, status is read from the drive with the updated LBA address. The 28 lower bits are then transposed into the NEXT drive commands upper 28bits. Confirmed: smartmon/sgtools using a Finisar protocol analyzer. When: Only occurs when using systems whos BIOS is set into Legacy (or ATA/IDE) modes. (Does NOT occur when using AHCI bios mode). See attached image to see what occured when running SG tools to read the SMART log (command 0x2F)... It becomes very obvious that the ATA Pass-Through driver's actual data becomes over-written with the previous commands LBA address. Example: DMA-Write LBA=00000123456 ->> BUS: Cmd 0x2f, LBA=0x0000123456 Read Status: DRDY, drive LBA=0x123457 (LBA updated in HW) Device Identify LBA=0000000000 ->> BUS: Cmd 0xec, LBA=12345700000 <-- BAD/OOPS!!! (In this case, CMD 0xec ignores LBA).. However, a cleverly constructed packet could use a read/writes combined with a previously corrupted LBA address to access portions of the drive which should be considered 'restricted/confidential', thus compromising system security and potentially by-passing AV or other security products. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
