Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[BUG] usbmsc: GET MAX LUN / MS-RESET EP0 stall in composite mode — wIndex checked against compile-time USBMSC_INTERFACEID instead of dynamic devinfo.ifnobase

Đang mở Phù hợp với người mới
#19,435 8 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
72/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
c

Hướng nghiên cứu

Đọc drivers/usbdev/usbmsc.c và usbmsc_setup(), sau đó so sánh các kiểm tra request của nó với việc gán interface động trong usbmsc_desc.c. Tái hiện hoặc kiểm tra GET MAX LUN và MS-RESET trong cấu hình composite, sử dụng bản chụp usbmon được mô tả để xác minh rằng chúng không còn bị stall. Được xem là hoàn tất khi USBMSC được mount trong khi cấu hình standalone và các interface CDC vẫn không bị ảnh hưởng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Description

On a composite USB device that includes USBMSC (tested: CDC-ACM + CDC-NCM + USBMSC on
RP2350 / Raspberry Pi Pico 2 W), the Mass-Storage class control requests GET MAX LUN and
Bulk-Only Mass Storage Reset are answered with an EP0 STALL instead of the expected
response. macOS retries GET MAX LUN ~6 times over ~4 s and then, critically, reads a
garbage LUN count off the failed control transfer and probes phantom LUNs — after which
the drive never mounts. Linux tolerates the stall (assumes a single LUN) but the stall is
still wrong and observable.

This is not rp23xx/rp2040-specific — it is a generic bug in drivers/usbdev/usbmsc.c
that affects any composite configuration where the USBMSC interface number is not zero.

Root cause

usbmsc_setup() in drivers/usbdev/usbmsc.c validates the target interface of the
class/interface requests by comparing the request's wIndex against the compile-time
constant
USBMSC_INTERFACEID:

#define USBMSC_INTERFACEID (CONFIG_USBMSC_IFNOBASE + 0)   /* usbmsc.h, == 0 by default */

But in composite mode the USBMSC interface number is assigned dynamically by the
composite core and stored in priv->devinfo.ifnobase. The configuration descriptor is built
from that dynamic value:

/* usbmsc_desc.c */
dest->ifno = devinfo->ifnobase;   /* interface descriptor advertises the real ifno */

So the host correctly directs GET MAX LUN / MS-RESET / GET&SET-INTERFACE to
wIndex == devinfo.ifnobase (interface 4 in my composite layout), but usbmsc_setup()
checks index != USBMSC_INTERFACEID (4 != 0) → ret = -EDOM → the USB driver stalls EP0.

Four comparisons in usbmsc_setup() are affected (SET_INTERFACE, GET_INTERFACE, MSRESET,
GETMAXLUN); all use USBMSC_INTERFACEID where they should use priv->devinfo.ifnobase.

In the standalone (non-composite) case ifnobase == CONFIG_USBMSC_IFNOBASE, so the two are
equal and the bug is invisible — which is why it has gone unnoticed.

Fix

-                if (index != USBMSC_INTERFACEID)
+                if (index != priv->devinfo.ifnobase)

applied to the MSRESET and GETMAXLUN handlers (and the matching == test in the
GET/SET_INTERFACE handlers). Full diff below.

Reproduction and validation (RP2350, Raspberry Pi Pico 2 W, silicon; Linux host, usbmon)

Composite layout places USBMSC at interface 4. Forcing a fresh SCSI probe on Linux
(echo 3-4:1.4 > /sys/bus/usb/drivers/usb-storage/unbind, then bind) and capturing usbmon:

Before the fix — GET MAX LUN stalls:

S Ci:3:007:0 s a1 fe 0000 0004 0001 1 <     # GET MAX LUN, bmRequestType a1, wIndex=4
C Ci:3:007:0 -32 0                           # -EPIPE / EP0 STALL, 0 bytes

After the fix — GET MAX LUN succeeds:

S Ci:3:010:0 s a1 fe 0000 0004 0001 1 <
C Ci:3:010:0 0 1 = 00                         # 1 byte returned, value 0x00 = 1 LUN

No regression: the FAT drive still mounts/reads, CDC-NCM and CDC-ACM are unaffected, and
cold re-enumeration is clean.

macOS impact (the motivating symptom)

On macOS the composite's network + serial come up but no disk device is ever created.
The kernel log shows GET MAX LUN stalling (endpoint 0x00: status 0xe0005000 (pipe stalled))
6×, then Max LUNs reported as 28 with 0xe0005000 — macOS reads a junk LUN count from the
stalled transfer — after which a bulk-IN babble error on 0x87 right after READ CAPACITY
sends IOUSBMassStorageDriver into a reset/retry loop that gives up. The babble does not
reproduce on Linux (Linux never mis-reads the LUN count). The working hypothesis is that the
babble is downstream of the phantom-LUN probing caused by the GET MAX LUN stall; a Mac
re-test of the fixed image is in progress. Either way the GET MAX LUN stall is a real,
independently-confirmed bug and the correct first fix.

Related

Same driver family and hardware as #19434 (rp2040/rp23xx cold-plug pull-up loss). This one
is in the generic drivers/usbdev/usbmsc.c layer rather than the arch USB driver.

Environment

  • NuttX board branch tracking recent master; drivers/usbdev/usbmsc.c, usbmsc_desc.c,
    usbmsc.h.
  • RP2350, Raspberry Pi Pico 2 W, composite CDC-ACM + CDC-NCM + USBMSC (USBMSC at interface 4).
  • Hosts: Linux (usbmon/sg_raw, reproduced + fix-validated), macOS (motivating symptom).

Disclosure

This investigation, root-cause analysis, and the tested fix were performed by an AI agent
(Claude Code), operated and directed by the submitter, and the results were reviewed by the
submitter before posting. Happy to provide the full usbmon captures, the macOS kernel-log
excerpts, or test any proposed alternative fix on hardware.

Ngôn ngữ chính
C
Star
4.1k
Fork
1.7k
Merge trung bình
1 ngày 10 giờ
Pull request đã merge (30 ngày)
649

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/nuttx

Tất cả issue của apache/nuttx

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.