https://bugzilla.kernel.org/show_bug.cgi?id=201221

            Bug ID: 201221
           Summary: USB drive shows up with write protection enabled
           Product: IO/Storage
           Version: 2.5
    Kernel Version: 4.14.44-4.19
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: SCSI
          Assignee: linux-scsi@vger.kernel.org
          Reporter: ta...@tasossah.com
        Regression: No

Created attachment 278743
  --> https://bugzilla.kernel.org/attachment.cgi?id=278743&action=edit
Kernel log

I have a "Kingston DT Ultimate G3" USB flash drive that was functioning
normally with past kernels. In newer ones, however, it shows up as having write
protection enabled, making it unable to be written to.

I have verified that it is not a hardware issue, by testing it on various
computers with different operating systems, and the issue only happened on
stable kernel 4.14 and newer. Other kernels are possibly affected too, but I
haven't checked it.

Bisecting the kernel showed that commit
20bd1d026aacc5399464f8328f305985c493cde3 [1], is the cause of this issue.

It appears that the normal behaviour of this flash drive is to first show up as
being write protected, and presumably after it is done initialising, it
disables write protection.

I believe that the commit mentioned above doesn't account for drives that may
disable write protection later on, resulting in this issue.

Running "blockdev --setrw /dev/sdX && blockdev --rereadpt /dev/sdX" allows the
drive to continue functioning normally and be written to until it gets
unplugged.

Reverting the changes done by that commit also resolves this issue.

Attached is the kernel (4.18.7) log during device init, and an attempt to mount
the partition on it immediately afterwards.

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20bd1d026aacc5399464f8328f305985c493cde3

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to