[Bug 220422] New: USB: Misdecoded serial number from Dymo Twin Turbo (0922:0018) breaks multi-device support in CUPS

[bugzilla-daemon@kernel.org]

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

            Bug ID: 220422
           Summary: USB: Misdecoded serial number from Dymo Twin Turbo
                    (0922:0018) breaks multi-device support in CUPS
           Product: Drivers
           Version: 2.5
    Kernel Version: Mainline
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: drivers_usb@kernel-bugs.kernel.org
          Reporter: steve@groesz.org
        Regression: No

Created attachment 308461
  --> https://bugzilla.kernel.org/attachment.cgi?id=308461&action=edit
Dymo Twin Turbo Packet Capture

**Summary:**
The Linux USB core incorrectly decodes the serial number string descriptor of
the Dymo LabelWriter Twin Turbo printer (USB ID 0922:0018), resulting in
invalid or unreadable characters. This causes user-space tools such as CUPS to
generate incorrect or duplicate URIs, making it difficult or impossible to use
more than one device concurrently.

**System:**

* Distribution: Linux Mint 22.1
* Kernel: 6.8.0-71-generic (also affects mainline kernels)
* Architecture: x86\_64
* Device: Dymo LabelWriter Twin Turbo
* USB ID: 0922:0018

**Steps to Reproduce:**

1. Connect two Dymo Twin Turbo printers via USB.
2. Inspect `/sys/bus/usb/devices/*/serial` — the serials differ in raw binary
but decode to unreadable (non-ASCII) strings.
3. Run:
   `lpinfo -v | grep usb`
   → Both devices appear as:
   `usb://DYMO/LabelWriter%20Twin%20Turbo?serial=??????????????`

**Problem:**
Each printer reports a unique serial number at the descriptor level, but the
raw USB string descriptor data is misaligned or malformed. For example:

```
b'\x30\x30\x00\x36\x00\x31\x00\x30\x00\x33\x00\x30\x00\x31\x00\x30\x00\x31\x00\x36\x00\x31\x00\x35\x00\x37\x00\x35'
```

This is not properly aligned for UTF-16LE decoding. The kernel’s USB string
decoder (`usb_string_sub()` in `drivers/usb/core/message.c`) treats high bytes
as non-ASCII and replaces them with `?`, resulting in a decoded string like:

```
??????????????
```

This leads CUPS and other tools to construct identical URIs for both devices,
preventing proper multi-device support.

**Analysis:**
The descriptor appears to contain valid UTF-16LE if the first byte is skipped.
After correcting for this offset, the decoded string is:

```
"006103010161575"
```

This matches the `GET_DEVICE_ID` response from the device, confirming the
intended serial value.

The decoding logic in `usb_string_sub()` assumes correct UTF-16LE alignment and
does not handle malformed or misaligned descriptors, causing loss of unique
identifiers in sysfs and downstream applications.

**Expected Behavior:**
The kernel should decode USB string descriptors defensively, including recovery
from common misalignment issues in UTF-16LE encoding. Devices that return
malformed descriptors should still expose unique serial numbers if the raw data
permits recovery.

**Suggested Fixes:**

* Add fallback decoding logic (e.g., try shifted decoding if the result is all
`?`)
* Add a USB quirk for device ID 0922:0018 to apply corrected decoding
* Optionally expose raw descriptor data in sysfs for user-space tools to
perform recovery

I have attached a wireshark packet capture with sample packets from one device.
I can provide additional packet captures if needed.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.