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: <2025081428-unfold-shakily-6278@gregkh>
Date: Thu, 14 Aug 2025 19:06:41 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Zenm Chen <zenmchen@...il.com>, 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 12:21:16PM -0400, Alan Stern wrote:
> 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>

Thanks, I have it somewhere, I'll dig it up and apply it.

greg k-h