linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 32362] New: ATA Passthrough generates incorrect LBA addresses with OS ASYNC activity, Image of Bus-trace attached
Date: Thu, 31 Mar 2011 16:11:08 GMT	[thread overview]
Message-ID: <bug-32362-11613@https.bugzilla.kernel.org/> (raw)

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@kernel-bugs.osdl.org
        ReportedBy: marcus.firthview@gmail.com
        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.

             reply	other threads:[~2011-03-31 16:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-31 16:11 bugzilla-daemon [this message]
2012-05-12 14:49 ` [Bug 32362] ATA Passthrough generates incorrect LBA addresses with OS ASYNC activity, Image of Bus-trace attached bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-32362-11613@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).