CVE-2022-29246
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedAzure RTOS USBX is a USB host, device, and on-the-go (OTG) embedded stack. Prior to version 6.1.11, he USBX DFU UPLOAD functionality may be utilized to introduce a buffer overflow resulting in overwrite of memory contents. In particular cases this may allow an attacker to bypass security features or execute arbitrary code. The implementation of `ux_device_class_dfu_control_request` function does not assure that a buffer overflow will not occur during handling of the DFU UPLOAD command. When an attacker issues the `UX_SLAVE_CLASS_DFU_COMMAND_UPLOAD` control transfer request with `wLenght` larger than the buffer size (`UX_SLAVE_REQUEST_CONTROL_MAX_LENGTH`, 256 bytes), depending on the actual implementation of `dfu -> ux_slave_class_dfu_read`, a buffer overflow may occur. In example `ux_slave_class_dfu_read` may read 4096 bytes (or more up to 65k) to a 256 byte buffer ultimately resulting in an overflow. Furthermore in case an attacker has some control over the read flash memory, this may result in execution of arbitrary code and platform compromise. A fix for this issue has been included in USBX release 6.1.11. As a workaround, align request and buffer size to assure that buffer boundaries are respected.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceAzure RTOS USBX contains a buffer overflow vulnerability in the DFU UPLOAD functionality. The `ux_device_class_dfu_control_request` function fails to validate that the `wLength` parameter from incoming USB control transfers does not exceed the buffer size (256 bytes). When an attacker sends a UPLOAD request with wLength up to 65k bytes, the `ux_slave_class_dfu_read` callback writes beyond the 256-byte buffer, allowing memory corruption that can lead to arbitrary code execution.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data< 6.1.11CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify USBX version in useSearch for USBX version definition in your codebase, typically found in header files like ux_user.h, ux_api.h, or check your dependency manifest/package.json for the ThreadX USBX version. Look for version constants such as UX_VERSION_MAJOR, UX_VERSION_MINOR, or version strings.Affected if The installed version is earlier than 6.1.11 (e.g., 6.1.10, 6.1.9, or any 6.x version below 6.1.11)
-
Verify DFU class is enabledCheck your USBX configuration files (typically ux_user.h or build configuration) for the DFU class enable flag, commonly defined as UX_DEVICE_CLASS_DFU_ENABLE or similar. Also search your initialization code for calls to ux_device_class_dfu_start.Affected if DFU class support is compiled in and the ux_device_class_dfu_start function is called in your initialization flow
-
Check for DFU UPLOAD request handlingInspect your USB device descriptor and request handling code for UPLOAD class requests (DFU_UPLOAD, typically request type 0x21 with request 0x00). Search for where ux_device_class_dfu_control_request processes incoming control transfers.Affected if Your firmware handles DFU UPLOAD control requests from the host and passes them to the DFU class handler
-
Inspect buffer allocation for DFU readLocate where the 256-byte buffer is allocated for DFU read operations. Search for buffers passed to ux_slave_class_dfu_read callback or within the ux_device_class_dfu_* structures. Check if the buffer size is hardcoded to 256 or defined by a constant.Affected if The DFU read buffer is limited to 256 bytes and wLength validation against this boundary is not performed before data transfer
You are affected if your Eclipse ThreadX USBX version is below 6.1.11 AND your device has DFU UPLOAD functionality enabled, allowing hosts to request more than 256 bytes which could overflow the internal buffer.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped6.1.11
Update USBX to version 6.1.11 or later which contains the fix. As a workaround, ensure request and buffer sizes are properly aligned and boundaries respected in custom `ux_slave_class_dfu_read` implementations.
USBX 6.1.11
- Upgrade Azure RTOS USBX to version 6.1.11 or later from the official Microsoft/Azure RTOS repository
- Verify the upgrade by checking that the `ux_device_class_dfu_control_request` function now properly validates `wLength` against `UX_SLAVE_REQUEST_CONTROL_MAX_LENGTH` (256 bytes) before processing DFU UPLOAD commands
- If upgrade is not immediately possible, implement a workaround in the application code: add validation to ensure that any DFU UPLOAD request's `wLength` parameter does not exceed the buffer size (256 bytes) before passing it to `ux_device_class_dfu_control_request`
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation4.0 h
- Implementation8.0 h
- Testing8.0 h
- Review / QA4.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $6,656.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2022-29246 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2022-29246 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data