Eclipse ThreadX USBX CVE-2025-55096

Requires a device running Eclipse ThreadX USBX before 6.4.3 operating as a USB HOST with the HID class driver enabled, plus an attacker-supplied or malicious USB HID device that is physically/locally attached and presents a crafted (malformed-length) HID report descriptor parsed by _ux_host_class_hid_report_descriptor_get(). Exploitation is LIMITED by: the need for local/physical access to connect the malicious device (no remote vector), high attack complexity (AC:H - reliable triggering depends on parser state and specific malformed field values), and the fact that the outcome is only a bounded out-of-bounds read yielding minor memory disclosure, not code execution or denial of service.

This is a low-priority, low-real-risk issue despite being a memory-safety bug. All signals align toward low severity: the vendor CVSS 4.0 base score is 2.1 (AV:L/AC:H/AT:N/PR:N/UI:N with only VC:L/VI:L and no availability impact), EPSS is 0.17% (5th percentile, i.e. very low predicted exploitation probability), it is NOT on the CISA KEV list, and no public exploit code is referenced. Exploitation status: no public exploit identified at time of analysis. The CWE classification (CWE-191, integer underflow) and the 'Integer Overflow' tag indicate a wraparound leading to an out-of-bounds READ during HID descriptor parsing, which matches the low confidentiality/integrity impact and absence of availability impact in the vector. One signal to verify: the vendor rated attack vector as AV:L (local), but the root cause - parsing a descriptor from a physically attached malicious USB HID device - realistically implies physical access (AV:P); this nuance does not change the overall low-risk conclusion. No conflicting data suggesting elevated risk was found.

An attacker with the ability to attach a USB device (or substitute a malicious one) presents a crafted HID report descriptor to a host running USBX before 6.4.3; the malformed length/count field triggers an integer underflow in _ux_host_class_hid_report_descriptor_get(), causing the parser to read out of bounds and potentially leak small amounts of adjacent memory. No public exploit code exists, and the high attack complexity plus local/physical access requirement make opportunistic exploitation unlikely.