Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#11,287 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@Old-Ding arbeitet bereits daran.

Seit 01.7.2026.

  • #11546 von @Old-Ding — offen

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Ruhig
Tech-Stack
c
Bereich
embedded-iot, operating-systems, security

Rechercherichtung

Beginnen Sie bei components/legacy/usb/usbdevice/core/usbdevice_core.c:689 und verfolgen Sie rt_usbd_ep0_write() bei 2093 durch den EP0 IN-Handler bei 1955, wobei Sie die Prüfungen der Grenzen des Standarddeskriptors in den Zeilen 49, 79 und 146 vergleichen. Überprüfen Sie die WinUSB- und RNDIS-Registrierungspfade bei winusb.c:359 und rndis.c:1405 und reproduzieren Sie anschließend die übergroße wLength-Anfrage; fertig ist die Aufgabe, wenn keine Antwortlesevorgänge über die Größe des erstellten Deskriptors hinausgehen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
C
Sterne
12.3k
Forks
5.5k
Ø Merge
7 T. 4 Std.
Gemergte PRs (30 T.)
34

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus RT-Thread/rt-thread

Alle Issues in RT-Thread/rt-thread

Ähnliche Issues

Weitere Issues zu C

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.