mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

             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®