[BUG] usbmsc: GET MAX LUN / MS-RESET EP0 stall in composite mode — wIndex checked against compile-time USBMSC_INTERFACEID instead of dynamic devinfo.ifnobase
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
- Lĩnh vực
- embedded-iot, operating-systems
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
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của apache/nuttx
-
Arch: all Area: Drivers OS: Linux Type: Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Arch: all Area: Drivers OS: Linux Type: Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Type: Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
apache/nuttx#17343 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Arch: all OS: Linux Type: Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
apache/nuttx#16249 · 7 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] fs/vfs: Release resources on O_NOFOLLOW symlink failureCó thể đã có người làm @arnavsharma990 đã nhận 1 ngày trước. Đang mởArch: simulator Area: File System OS: Mac Type: Bug
Độ khó 3/5 Nửa ngày Mức phù hợp với người mới 67/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
cyrusimap/cyrus-imapd#6640 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 60/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
GalusPeres/HomeTiles#139 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
DaveGamble/cJSON#1122 ·
Maintainer thường phản hồi trong vòng 12 ngày
-
Type: Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
apache/nuttx-apps#3942 ·
Maintainer thường phản hồi trong vòng 1 ngày