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] legacy usbdevice core trusts host-controlled wLength for Microsoft OS Compatible ID descriptor responses, causing heap out-of-bounds read and information disclosure

Đang mở
  • Có gì không ổn?
#11,287 0 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ó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
68/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, security

Hướng nghiên cứu

Bắt đầu tại components/legacy/usb/usbdevice/core/usbdevice_core.c:689 và lần theo rt_usbd_ep0_write() ở dòng 2093 qua trình xử lý EP0 IN ở dòng 1955, đồng thời so sánh các kiểm tra giới hạn của descriptor chuẩn tại các dòng 49, 79 và 146. Kiểm tra các đường dẫn đăng ký WinUSB và RNDIS trong winusb.c:359 và rndis.c:1405, sau đó tái hiện yêu cầu wLength quá lớn; hoàn thành khi không có thao tác đọc phản hồi nào vượt quá kích thước descriptor đã được tạo.

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

Mô tả

RT-Thread Version

master, verified on commit 2b58dec87b584aa7ded6e8c736498716f8d29cd0

Hardware Type/Architectures

Any BSP using the legacy USB device stack with a class that registers Microsoft OS Compatible ID descriptors, such as WinUSB or RNDIS

Develop Toolchain

GCC

Describe the bug
Summary

A heap out-of-bounds read / information disclosure vulnerability exists in RT-Thread's legacy USB device core when handling the Microsoft OS Compatible ID descriptor vendor request.

The legacy USB device core dynamically allocates a heap buffer for the Microsoft OS Compatible ID descriptor using the real descriptor size, but later sends it using the USB host-controlled wLength field from the SETUP packet instead of clamping to the actual allocated size.

As a result, a malicious USB host can request more bytes than the descriptor actually contains and cause the device to transmit heap memory beyond the end of the allocated descriptor buffer over EP0 IN.

This is not a device-fixed length field. wLength comes from the host-supplied USB control request.

Vulnerability Details

I verified the following code path on current master.

1. wLength is host-controlled

The USB host sends an 8-byte SETUP packet, and RT-Thread copies it into struct urequest. That includes wLength.

Relevant locations:

  • components/legacy/usb/usbdevice/core/usbdevice_core.c:1927
  • components/drivers/include/drivers/usb_common.h:468

So wLength is controlled by the USB host, not generated by the device.

2. Other descriptor paths do clamp to real size

RT-Thread already handles standard descriptor responses defensively by using min(real_size, setup->wLength) style logic.

Examples:

  • components/legacy/usb/usbdevice/core/usbdevice_core.c:49
  • components/legacy/usb/usbdevice/core/usbdevice_core.c:79
  • components/legacy/usb/usbdevice/core/usbdevice_core.c:146

That shows the codebase already recognizes that wLength must be bounded by the real descriptor size.

3. The Microsoft OS Compatible ID descriptor path does not clamp

In the vendor-request handler, RT-Thread calculates the real descriptor size into usb_comp_id_desc_size, allocates exactly that many heap bytes, and fills the descriptor.

But it then responds with:

rt_usbd_ep0_write(device, (void*)usb_comp_id_desc, setup->wLength);

Relevant location:

  • components/legacy/usb/usbdevice/core/usbdevice_core.c:689

This means the transmitted length is controlled by the host, not by the real allocated descriptor size.

4. rt_usbd_ep0_write() does not truncate

rt_usbd_ep0_write() directly stores the supplied size into the EP0 request bookkeeping:

  • request.size
  • request.remain_size

Relevant location:

  • components/legacy/usb/usbdevice/core/usbdevice_core.c:2093

So there is no later truncation stage that would save this path.

5. The IN handler keeps advancing and sending until the host-controlled size is satisfied

The EP0 IN path keeps moving the buffer pointer and sending data until remain_size reaches zero.

Relevant location:

  • components/legacy/usb/usbdevice/core/usbdevice_core.c:1955

So this is not limited to sending one oversized first packet. It can continue reading and transmitting memory beyond the allocated descriptor buffer until the full host-supplied wLength has been satisfied.

6. The path is reachable in real configurations

This path is reachable because at least these legacy USB device classes register Microsoft OS Compatible ID descriptors:

  • components/legacy/usb/usbdevice/class/winusb.c:359
  • components/legacy/usb/usbdevice/class/rndis.c:1405

That makes the bug reachable in WinUSB/RNDIS-enabled legacy USB device builds.

Security Impact

If the threat model includes a malicious or compromised USB host, this is a real information disclosure vulnerability.

A hostile host can craft the vendor request so that wLength is larger than the actual descriptor size and receive heap bytes beyond the end of the descriptor buffer.

The practical impact is:

  • Heap memory disclosure to the USB host
  • Possible exposure of adjacent heap objects or pointer-like values
  • Possible denial of service if the over-read reaches invalid memory and faults

If the product only connects to fully trusted USB hosts, the attack surface is smaller, but the bug still exists.

Steps to Reproduce
  1. Build RT-Thread with the legacy USB device stack enabled.
  2. Enable a legacy USB device class that registers Microsoft OS Compatible ID descriptors, such as WinUSB or RNDIS.
  3. Connect the RT-Thread device to a malicious or instrumented USB host.
  4. Send the Microsoft OS Compatible ID descriptor vendor request handled by the legacy USB device core.
  5. Set wLength to a value larger than the actual allocated Compatible ID descriptor length.
  6. Read the EP0 IN response.

Expected observation: the device returns data beyond the end of the real Compatible ID descriptor buffer.

Expected Behavior

RT-Thread should clamp the response size to the real constructed descriptor length, for example:

min(setup->wLength, usb_comp_id_desc_size)

The device must never transmit memory beyond the allocated descriptor buffer.

Actual Behavior

RT-Thread uses the host-controlled setup->wLength as the EP0 response length and continues sending until that full length is satisfied, even if it exceeds the real allocated descriptor size.

This can disclose adjacent heap memory to the USB host and may also cause faults on some targets.

Kindly let me know if you intend to request a CVE ID upon confirmation of the vulnerability.

Other additional context

No response

Ngôn ngữ chính
C
Star
12.3k
Fork
5.5k
Merge trung bình
4 ngày 11 giờ
Pull request đã merge (30 ngày)
33

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

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

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 RT-Thread/rt-thread

Tất cả issue của RT-Thread/rt-thread

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.