linux-kernel - Re: [RESEND PATCH v3] scsi: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <F8C142341D03C19E+0f802042-6f12-43f3-bd2f-ce5463f6ae11@uniontech.com>
Date: Thu, 27 Mar 2025 00:51:03 +0800
From: WangYuli <wangyuli@...ontech.com>
To: "Martin K. Petersen" <martin.petersen@...cle.com>
Cc: James.Bottomley@...senPartnership.com, linux-scsi@...r.kernel.org,
 linux-kernel@...r.kernel.org, stern@...land.harvard.edu, bvanassche@....org,
 zhanjun@...ontech.com, niecheng1@...ontech.com, guanwentao@...ontech.com,
 Xinwei Zhou <zhouxinwei@...ontech.com>, Xu Rao <raoxu@...ontech.com>,
 Yujing Ming <mingyujing@...ontech.com>
Subject: Re: [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks
 with "use_192_bytes_for_3f" attribute

Hi Martin K. Petersen,

On 2025/3/21 09:08, Martin K. Petersen wrote:
> I am really not a fan of using in-kernel workarounds to intercept
> passthrough commands.
>
> Why does does lshw perform a MODE SENSE in the first place? What
> information is it looking for that isn't available in sysfs?

I know this is a workaround to solve the problem at the application layer.

The problem is that the kernel does not know what operations the 
application will do to the disk through ioctl.

Intercepting this illegal command in kernel mode will help improve the 
stability of the system.

The following is the log of the exception I caught:

10:22:22 2024] queue cmd =====1a 00 3f 00 ff 00 10:22:22 2024] CPU: 7 
PID: 6000 Comm: lshw Tainted: G O 4.19.0-arm64-desktoptest #197 10:22:22 
2024] Hardware name: THTF ChaoXiang Series/THTF-FTD3000-ZX200-MF281C, 
BIOS KL4.28.BXC.D.016.241025.R 10/25/2024 17:51:51 10:22:22 2024] Call 
trace: 10:22:22 2024] dump_backtrace+0x0/0x1a0 10:22:22 2024] 
show_stack+0x24/0x30 10:22:22 2024]dump_stack+0xa8/0xcc 10:22:22 2024] 
queuecommand+0xbc/0x198 [usb_storage] 10:22:22 2024] 
scsi_dispatch_cmd+0xa4/0x298 10:22:22 2024]scsi_request_fn+0x47c/0x7a8 
10:22:22 2024] __blk_run_queue+0x50/0x88 10:22:22 2024] 
blk_execute_rq_nowait+0xe0/0x160 10:22:22 2024] 
sg_common_write.isra.11+0x254/0x6c0 10:22:22 2024] 
sg_new_write.isra.12+0x178/0x308 10:22:22 2024] sg_ioctl+0xeb4/0x11d8 
10:22:22 2024] do_vfs_ioctl+0xb0/0x868 10:22:22 2024] 
ksys_ioctl+0x84/0xb8 10:22:22 2024] __arm64_sys_ioctl+0x28/0x38 10:22:22 
2024] el0_svc_common+0xa0/0x190 10:22:22 2024] el0_svc_handler+0xac/0xb8 
10:22:22 2024] el0_svc+0x8/0xc

I encountered this problem in multiple devices, causing the disk to be 
unrecognizable. I think it is necessary to do this to make the system 
more robust.

Thanks,
-- 
WangYuli

Download attachment "OpenPGP_0xC5DA1F3046F40BEE.asc" of type "application/pgp-keys" (633 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)