Re: [patch 34/37] libata bugfix: HDIO_DRIVE_TASK

[Greg KH]

On Fri, Mar 30, 2007 at 05:42:13PM -0400, Mark Lord wrote:
> Greg KH wrote:
> >-stable review patch.  If anyone has any objections, please let us know.
> >
> >------------------
> >From: Mark Lord <liml@xxxxxx>
> >
> >libata bugfix: HDIO_DRIVE_TASK
> >
> >I was trying to use HDIO_DRIVE_TASK for something today,
> >and discovered that the libata implementation does not copy
> >over the upper four LBA bits from args[6].
> >
> >This is serious, as any tools using this ioctl would have their
> >commands applied to the wrong sectors on the drive, possibly resulting
> >in disk corruption.
> >
> >Ideally, newer apps should use SG_IO/ATA_16 directly,
> >avoiding this bug.  But with libata poised to displace drivers/ide,
> >better compatibility here is a must.
> >
> >This patch fixes libata to use the upper four LBA bits passed
> >in from the ioctl.
> >
> >The original drivers/ide implementation copies over all bits
> >except for the master/slave select bit.  With this patch,
> >libata will copy only the four high-order LBA bits,
> >just in case there are assumptions elsewhere in libata (?).
> >
> >Signed-off-by: Mark Lord <mlord@xxxxxxxxx>
> >Cc: Chuck Ebbert <cebbert@xxxxxxxxxx>
> >Signed-off-by: Jeff Garzik <jeff@xxxxxxxxxx>
> >Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
> ..
> 
> Mmmm.. I've just noticed another bit we should  be preserving there,
> both for *stable* and current mainline.
> 
> Instead of:
> 
> >+	scsi_cmd[13] = args[6] & 0x0f;
> 
> We should be doing:
> 
> >+	scsi_cmd[13] = args[6] & 0x4f;
> 
> As-is, the patch still helps, but it is not as useful as it could be.
> Here's the fixed version.  I'm also sending out a 2.6.21 patch via Jeff.
> 
> Signed-off-by: Mark Lord <mlord@xxxxxxxxx>

Can you forward that one to the stable@xxxxxxxxxx address too, with the
full changelog and Jeff's ack/signed-off-by so that I will remember to
add it to the tree?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/