Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[Bug] legacy USB host trusts device-controlled bNumInterfaces and can trigger out-of-bounds access in fixed interface array

Ouverte
  • Quelque chose ne va pas ?
#11,288 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@manyangshen y travaille déjà.

Depuis le 22/9/2026.

  • #11822 par @manyangshen — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Calme
Stack technique
c
Domaine
embedded-iot, operating-systems, security

Piste de recherche

Commencez par USB_MAX_INTERFACE et struct uinstance dans components/legacy/usb/usbhost/core/usbhost_core.c, puis examinez les boucles d’attach et de detach aux emplacements indiqués ainsi que le chemin du hub dans hub.c:452. Vérifiez comment bNumInterfaces circule pendant l’énumération et le nettoyage. Le travail est terminé lorsque les deux chemins gèrent correctement les valeurs supérieures à la capacité du tableau fixe, y compris les échecs partiels d’attach.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

RT-Thread Version

master, verified on current worktree at commit 25295501c0cc7181d6a541a867fdf7214879ddf8

Hardware Type/Architectures

Any BSP enabling the legacy USB host stack and connecting to external USB devices

Develop Toolchain

GCC

Describe the bug
Summary

A memory-safety issue exists in RT-Thread's legacy USB host stack because it trusts the device-controlled bNumInterfaces field from the USB configuration descriptor, but stores interface state in a fixed-size internal array of only 8 entries.

USB_MAX_INTERFACE is fixed at 8, and struct uinstance contains only:

struct uhintf *intf[USB_MAX_INTERFACE];

However, the USB device's configuration descriptor field bNumInterfaces is attacker-controlled external input, and both attach and detach paths iterate directly up to device->cfg_desc->bNumInterfaces without comparing it against USB_MAX_INTERFACE.

This makes out-of-bounds access reachable from a malicious USB device.

Relevant Code

Internal capacity limit:

  • components/drivers/include/drivers/usb_host.h:22
  • components/drivers/include/drivers/usb_host.h:66
#define USB_MAX_INTERFACE 0x08

struct uinstance
{
    ...
    struct uhintf *intf[USB_MAX_INTERFACE];
    ...
};

Untrusted external field:

  • components/drivers/include/drivers/usb_common.h:294
rt_uint8_t bNumInterfaces;

Attach path:

  • components/legacy/usb/usbhost/core/usbhost_core.c:190
  • components/legacy/usb/usbhost/core/usbhost_core.c:229
for (i = 0; i < device->cfg_desc->bNumInterfaces; i++)
{
    ...
    device->intf[i] = (struct uhintf *)rt_malloc(sizeof(struct uhintf));
    ...
}

Detach path:

  • components/legacy/usb/usbhost/core/usbhost_core.c:276
for (i = 0; i < device->cfg_desc->bNumInterfaces; i++)
{
    if (device->intf[i] == RT_NULL) continue;
    ...
}

Hub path that makes follow-on detach realistic even if attach fails partway:

  • components/legacy/usb/usbhost/core/hub.c:452

The attach return value is not handled in a way that prevents later detach-driven access from the same untrusted device lifecycle.

Correct Vulnerability Characterization

The issue is real, but the trigger conditions need to be stated precisely.

1. Out-of-bounds read is the easiest effect to reach

Because the detach path also trusts bNumInterfaces, a malicious USB device can cause the host to read past the 8-entry intf[] array during later disconnect / reconnect / cleanup flows.

2. Out-of-bounds write is also reachable

It is not enough to set only bNumInterfaces = 9. To actually reach the write at device->intf[i] = ... for i >= 8, the malicious USB device must also provide interface descriptors with indices beyond 7, and those descriptors must match an enabled host class driver so that the allocation path is taken.

If those conditions are met, device->intf[i] becomes a real out-of-bounds write.

3. Static storage makes corruption more dangerous

struct uinstance objects come from a static array:

  • components/legacy/usb/usbhost/core/usbhost_core.c:18
static struct uinstance dev[USB_MAX_DEVICE];

So writing beyond intf[7] is likely to corrupt adjacent fields of the same instance or neighboring device instances, not harmless padding.

Why This Is a Security Issue

This bug is reachable from an untrusted USB device during normal host-side enumeration.

A malicious USB peripheral can provide a crafted configuration descriptor with an oversized bNumInterfaces value and additional interface descriptors designed to drive the host into out-of-bounds access.

This is not just a robustness issue. It is a real memory-safety problem in the legacy USB host stack, with at least:

  • Out-of-bounds read during detach / cleanup
  • Out-of-bounds write during attach if enough matching interfaces are supplied

Depending on target layout and allocator behavior, the practical impact may include:

  • Crash
  • Denial of service
  • Corruption of adjacent host USB state
  • Undefined behavior during later device handling
Steps to Reproduce

A practical PoC should use a programmable USB device/emulator (for example a USB gadget setup, Facedancer-like platform, or custom firmware) and present a crafted configuration descriptor.

Minimal Out-of-Bounds Read PoC
  1. Enable RT-Thread legacy USB host support.
  2. Connect a malicious USB device.
  3. Provide a configuration descriptor with:
    • bNumInterfaces > 8
    • Enough malformed or unsupported interface layout so the attach path does not fully populate all device->intf[] entries
  4. Trigger disconnect / reconnect or any path that causes cleanup / detach.
  5. Observe that the detach logic iterates up to the untrusted bNumInterfaces value and reads device->intf[i] past the 8-entry array.
Stronger Out-of-Bounds Write PoC
  1. Provide a crafted configuration descriptor with:
    • bNumInterfaces > 8
    • Actual interface descriptors for indices 0..8 or higher
    • Interface class/subclass values that match enabled host class drivers
  2. Let the host enumerate the device normally.
  3. When i >= 8, the attach logic writes to device->intf[i] even though the fixed array ends at intf[7].
Expected Behavior

RT-Thread should treat bNumInterfaces as untrusted input and reject or clamp any device that reports more interfaces than the internal host representation can store.

At minimum:

  • Reject bNumInterfaces > USB_MAX_INTERFACE
  • Avoid indexing device->intf[i] unless i < USB_MAX_INTERFACE
  • Apply the same validation consistently in both attach and detach paths
Actual Behavior

RT-Thread directly trusts bNumInterfaces from the device configuration descriptor and uses it to drive loops that index a fixed-size 8-entry internal array.

This allows a malicious USB device to cause out-of-bounds access in the legacy USB host stack.

Suggested Fix

The fix should be applied in all paths that use bNumInterfaces to index device->intf[], including both enumeration and detach/cleanup.

At minimum:

  • Reject or clamp device->cfg_desc->bNumInterfaces if it exceeds USB_MAX_INTERFACE
  • Do not allocate or access device->intf[i] unless i < USB_MAX_INTERFACE
  • Ensure failure during attach cannot leave a later detach path iterating on the untrusted original interface count

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

Other additional context

No response

Langage dominant
C
Étoiles
12.3k
Forks
5.5k
Merge moyen
4 j 12 h
PR mergées (30 j)
32

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de RT-Thread/rt-thread

Toutes les issues de RT-Thread/rt-thread

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.