[Bug] legacy usbdevice core trusts host-controlled wLength for Microsoft OS Compatible ID descriptor responses, causing heap out-of-bounds read and information disclosure

components/legacy/usb/usbdevice/core/usbdevice_core.c:689 から始め、2093 の rt_usbd_ep0_write() を 1955 の EP0 IN ハンドラまで追跡し、49、79、146 行目の標準ディスクリプタの境界チェックを比較します。winusb.c:359 と rndis.c:1405 の WinUSB および RNDIS の登録パスを確認し、その後、サイズの大きい wLength リクエストを再現します。構築されたディスクリプタのサイズを超えてレスポンスを読み取らなければ完了です。

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