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

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: [email protected]
          Reporter: [email protected]
        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.

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

--- Comment #1 from [email protected] ---
Created attachment 308462
--> https://bugzilla.kernel.org/attachment.cgi?id=308462&action=edit
lsusb data

Complete lsusb result for one of the label printers

You may reply to this email to add a comment.

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

The device should be fixed instead, how did this device pass the USB-IF testing framework?

thanks,

greg k-h

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

--- Comment #2 from [email protected] ---

The device should be fixed instead, how did this device pass the USB-IF testing framework?

thanks,

greg k-h

You may reply to this email to add a comment.

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

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

--- Comment #3 from [email protected] ---
The device in question is a Dymo Labelwriter printer. Unfortunately, it's an out of production model and I very much doubt the vendor will fix the device, even if they could. It would likely need it's USB chip replaced and no vendor would do that for an unsupported device.

As for how it passed USB-IF, I don't know.

This is why I believe a USB quirk patch would be most appropriate, to detect this device by it's VID:PID and slightly change how it decodes the unique device ID.

You may reply to this email to add a comment.

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

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

--- Comment #4 from [email protected] ---
the easiest (least code) fix would be to drop the first two bytes and decode the remaining data as utf-16-be (big endian) for affected devices. This will yield usable and unique values that can be safely used by upstream tools.

I don't mind writing a patch but I am struggling a bit to understand how quirks are written.

You may reply to this email to add a comment.

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

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

[email protected] changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |OBSOLETE

--- Comment #5 from [email protected] ---
This has been fixed in CUPs.

https://github.com/OpenPrinting/cups/issues/1338

You may reply to this email to add a comment.

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