linux-kernel - Re: [PATCH] usb-storage: Bypass certain SCSI commands on disks with "use_192_bytes_for

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 for Android: free password hash cracker in your pocket

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

Message-ID: <80ef917b-3680-4f85-93ba-c92d2b69ebaa@rowland.harvard.edu>
Date: Thu, 6 Feb 2025 09:58:18 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: WangYuli <wangyuli@...ontech.com>
Cc: gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
	usb-storage@...ts.one-eyed-alien.net, linux-kernel@...r.kernel.org,
	zhanjun@...ontech.com, guanwentao@...ontech.com,
	chenlinxuan@...ontech.com, Xinwei Zhou <zhouxinwei@...ontech.com>,
	Xu Rao <raoxu@...ontech.com>,
	Yujing Ming <mingyujing@...ontech.com>
Subject: Re: [PATCH] usb-storage: Bypass certain SCSI commands on disks with
 "use_192_bytes_for_3f" attribute

On Thu, Feb 06, 2025 at 01:41:07PM +0800, WangYuli wrote:
> On some external USB hard drives, mounting can fail if "lshw" is
> executed during the process.
> 
> This occurs because data sent to the device's output endpoint in
> certain abnormal scenarios does not receive a response, leading to
> a mount timeout.
> 
> [ Description of "use_192_bytes_for_3f" in the kernel code: ]
>   /*
>    * Many disks only accept MODE SENSE transfer lengths of
>    * 192 bytes (that's what Windows uses).
>    */
>    sdev->use_192_bytes_for_3f = 1;
> 
> The kernel's SCSI driver, when handling devices with this attribute,
> sends commands with a length of 192 bytes like this:
>   if (sdp->use_192_bytes_for_3f)
>   	res = sd_do_mode_sense(sdp, 0, 0x3F, buffer, 192, &data, NULL);
> 
> However, "lshw" disregards the "use_192_bytes_for_3f" attribute and
> transmits data with a length of 0xff bytes via ioctl, which can cause
> some hard drives to hang and become unusable.
> 
> To resolve this issue, prevent commands with a length of 0xff bytes
> from being queued via ioctl when it detects the "use_192_bytes_for_3f"
> attribute on the device.

Is usb-storage really the right place to put this test?  Wouldn't it
be better to put it in the SCSI layer where the ioctl is converted to
a SCSI command?  That way it would affect all SCSI devices with the
use_192_bytes_for_3f flag, not just USB devices.

Also, instead of making the command fail completely, wouldn't it be
better to change the transfer length to 192 if the original value was
larger?

Alan Stern