linux-kernel - Re: [usb-storage] Re: [PATCH] USB: storage: Ignore driver CD mode for Realtek multi-mode Wi-Fi dongles

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <b938a764-6ded-4b76-a15c-82c0062abf42@rowland.harvard.edu>
Date: Thu, 14 Aug 2025 12:21:16 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Zenm Chen <zenmchen@...il.com>
Cc: gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org, pkshih@...ltek.com,
	rtl8821cerfe2@...il.com, stable@...r.kernel.org,
	usb-storage@...ts.one-eyed-alien.net, usbwifi2024@...il.com
Subject: Re: [usb-storage] Re: [PATCH] USB: storage: Ignore driver CD mode
 for Realtek multi-mode Wi-Fi dongles

On Thu, Aug 14, 2025 at 10:03:29PM +0800, Zenm Chen wrote:
> > Also, can you collect a usbmon trace showing what happens when the dongle is plugged in?
> 
> Hi Alan,
> 
> Today I removed usb_modeswitch from my system and grabbed some data, could you please take
> a look what was wrong? many thanks!

Yes, this shows the problem.  I'll skip the unimportant stuff below.

> D-Link AX9U

...

> ffff8ae1f0bee000 771359614 S Bo:2:053:5 -115 31 = 55534243 0a000000 08000000 80000a25 00000000 00000000 00000000 000000
> ffff8ae1f0bee000 771359684 C Bo:2:053:5 0 31 >
> ffff8ae1b52d83c0 771359702 S Bi:2:053:4 -115 8 <
> ffff8ae1b52d83c0 771359812 C Bi:2:053:4 0 8 = 00007bff 00000200
> ffff8ae1f0bee000 771359853 S Bi:2:053:4 -115 13 <
> ffff8ae1f0bee000 771359935 C Bi:2:053:4 0 13 = 55534253 0a000000 00000000 00

This is a READ CAPACITY(10) command.  It asks the device for the number
of data blocks it contains and the size of each block.  The reply says
there are 31744 blocks each containing 512 bytes (which is unheard-of
for CDs; they virtually always have 2048 bytes per block).

...

> ffff8ae1f0bee000 771366235 S Bo:2:053:5 -115 31 = 55534243 17000000 0c000000 00000615 1000000c 00000000 00000000 000000
> ffff8ae1f0bee000 771366306 C Bo:2:053:5 0 31 >
> ffff8ae218ff2900 771366317 S Bo:2:053:5 -115 12 = 00000008 00000000 00000800
> ffff8ae218ff2900 771366432 C Bo:2:053:5 0 12 >
> ffff8ae1f0bee000 771366443 S Bi:2:053:4 -115 13 <
> ffff8ae1f0bee000 771366556 C Bi:2:053:4 0 13 = 55534253 17000000 0c000000 01

This is a MODE SELECT(6) command.  This one tells the device to change
the block size to 2048.  The device responds with an error indication.

> ffff8ae1f0bee000 771366567 S Bo:2:053:5 -115 31 = 55534243 18000000 12000000 80000603 00000012 00000000 00000000 000000
> ffff8ae1f0bee000 801899370 C Bo:2:053:5 -104 0

This is a REQUEST SENSE command; it asks the device to report the
details of the error condition from the previous command.  But the
device doesn't reply and the command times out.  From this point on,
the trace shows nothing but repeated resets.  They don't help and the
device appears to be dead.

I don't know of any reasonable way to tell the kernel not to send that
MODE SELECT(6) command.

The log for the Mercury is generally similar although the details are
different.  Everything works okay until the computer sends a command
that the device doesn't like.  At that point the device dies and
resets don't revive it.

So it does indeed look like there is no alternative to making
usb-storage ignore the devices.

Greg, do you still have the original patch email that started this 
thread?  You can add:

Acked-by: Alan Stern <stern@...land.harvard.edu>

Alan Stern