From: Xuntao Chi <chotaotao1qaz2wsx@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: [BUG] usb-storage: 14cd:1212 returns incorrect data after large READ(10)
Date: Tue, 13 Oct 2026 21:41:22 +0800 [thread overview]
Message-ID: <34f2ac0a-04d0-41cf-a2a4-11a93c7c9b91@gmail.com> (raw)
Hello,
I would like to report a deterministic silent read corruption issue with
14cd:1212 USB microSD readers and propose adding a MAX_SECTORS_64 quirk.
A READ(10) larger than 64 KiB can cause the following READ(10) to return
data from the wrong LBA. The trigger I have found is that the second
read starts 64 KiB beyond the end of the first read. Instead of honoring
that gap, the reader returns data starting at the end of the first read,
that is exactly 64 KiB before the requested address. Both commands
complete successfully, but the returned payload contains erroneous data.
The same problem is observed on 3 physically separate readers purchased
from 2 different OEMs, all identifying as 14cd:1212 and with the same
serial.
Device and environments
-----------------------
VID:PID: 14cd:1212
idVendor: Super Top
idProduct: microSD card reader (SY-T18)
bcdDevice: 1.00
iManufacturer: Generic
iProduct: Mass Storage Device
iSerial: 121220160204
speed: USB 2.0 high speed
driver: usb-storage
logical blocks: 512 bytes
The error is reproduced on an arm64 machine running 6.18.54 kernel, the
same machine running a 6.12.112 kernel, and an amd64 machine running
6.8.0 kernel, and is confirmed directly using libusb.
This has been observed to cause data silent data corrupting when
mounting an ext4 partition from the device, and setting
max_sectors_kb=64 as a workaround fixes it completely.
Would adding a US_FL_MAX_SECTORS_64 quirk be appropriate? I retest
against the latest mainline if needed.
Regards,
Xuntao Chi
next reply other threads:[~2026-10-13 13:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 13:41 Xuntao Chi [this message]
2026-10-13 14:18 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34f2ac0a-04d0-41cf-a2a4-11a93c7c9b91@gmail.com \
--to=chotaotao1qaz2wsx@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=usb-storage@lists.one-eyed-alien.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®