linux-kernel - BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADDb1s2Qhy1dNmjk+DhU=rf46A4X6kPdQ2rdpwK9zinY4Yv1mw@mail.gmail.com>
Date:	Wed, 28 Sep 2011 21:12:35 +0530
From:	Amit Sahrawat <amit.sahrawat83@...il.com>
To:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

When a USB HDD is connected to the device, it invokes slave_configure
to configure the USB HDD. In this function, whenever there is a SCSI
device of type TYPE_DISK, it sets:
	/* A number of devices have problems with MODE SENSE for
		 * page x08, so we will skip it. */
		sdev->skip_ms_page_8 = 1;

Now, as a part of SCSI device probing, in the function
sd_revalidate_disk()-->sd_read_cache_type(), there is a condition
if (sdp->skip_ms_page_8)
		goto defaults;
which becomes always true for all the USB HDD’s – the net result is
that the Write Cache is never considered for USB HDD(WCE = 0) –
“Assuming drive cache: write through”

What’s more – the QUEUE ordering which is marked for WCE=0 is
QUEUE_ORDERED_DRAIN, instead of QUEUE_ORDERED_DRAIN_FLUSH
This means there is no flushing of USB HDD internal cache (although
SYNCHRONIZE_CACHE is implemented as passed as command in
sd_prepare_flush) – queue_flush()(called in function
blk_do_ordered()-->start_ordered()) does not gets called in case of
QUEUE_ORDERED_DRAIN.

This causes a serious impact on USB HDD’s.

Please let me know in case I have missed something in my observations.

Thanks & Regards,
Amit Sahrawat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/