« Back to list

CVE-2022-39293

Status: ModifiedCritical (9.8)—

Azure RTOS USBX is a high-performance USB host, device, and on-the-go (OTG) embedded stack, that is fully integrated with Azure RTOS ThreadX. The case is, in [_ux_host_class_pima_read](https://github.com/azure-rtos/usbx/blob/master/common/usbx_host_classes/src/ux_host_class_pima_read.c), there is data length from device response, returned in the very first packet, and read by [L165 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L165), as header_length.

Read full descriptionShow less

Then in [L178 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L178), there is a “if” branch, which check the expression of “(header_length - UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE) > data_length” where if header_length is smaller than UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE, calculation could overflow and then [L182 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L182) the calculation of data_length is also overflow, this way the later [while loop start from L192](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L192) can move data_pointer to unexpected address and cause write buffer overflow. The fix has been included in USBX release [6.1.12](https://github.com/azure-rtos/usbx/releases/tag/v6.1.12_rel). The following can be used as a workaround: Add check of `header_length`: 1. It must be greater than `UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE`. 1. It should be greater or equal to the current returned data length (`transfer_request -> ux_transfer_request_actual_length`).

CVSS

Exploitation probability (EPSS)

EPSS (Exploit Prediction Scoring System, FIRST) estimates how likely a vulnerability is to be exploited in the wild within 30 days. It complements CVSS (impact) and CISA KEV (confirmed exploitation).

Affected technologies (1)

CWEs

References

Raw JSON (NVD)

Show
{
  "id": "CVE-2022-39293",
  "cveTags": [],
  "metrics": {
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2022-39293",
          "role": "CISA Coordinator",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "version": "2.0.3",
          "timestamp": "2025-04-23T15:49:58.111178Z"
        }
      }
    ],
    "cvssMetricV31": [
      {
        "type": "Secondary",
        "source": "security-advisories@github.com",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 8.6,
          "attackVector": "NETWORK",
          "baseSeverity": "HIGH",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
          "integrityImpact": "LOW",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "confidentialityImpact": "LOW"
        },
        "impactScore": 4.7,
        "exploitabilityScore": 3.9
      },
      {
        "type": "Primary",
        "source": "nvd@nist.gov",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 9.8,
          "attackVector": "NETWORK",
          "baseSeverity": "CRITICAL",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "integrityImpact": "HIGH",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 5.9,
        "exploitabilityScore": 3.9
      }
    ]
  },
  "affected": [
    {
      "source": "security-advisories@github.com",
      "affectedData": [
        {
          "vendor": "azure-rtos",
          "product": "usbx",
          "versions": [
            {
              "status": "affected",
              "version": "< 6.1.12"
            }
          ]
        }
      ]
    }
  ],
  "published": "2022-10-13T19:15:09.750",
  "references": [
    {
      "url": "https://github.com/azure-rtos/usbx/releases/tag/v6.1.12_rel",
      "tags": [
        "Release Notes",
        "Third Party Advisory"
      ],
      "source": "security-advisories@github.com"
    },
    {
      "url": "https://github.com/azure-rtos/usbx/security/advisories/GHSA-gg76-h537-xq48",
      "tags": [
        "Patch",
        "Third Party Advisory"
      ],
      "source": "security-advisories@github.com"
    },
    {
      "url": "https://github.com/azure-rtos/usbx/releases/tag/v6.1.12_rel",
      "tags": [
        "Release Notes",
        "Third Party Advisory"
      ],
      "source": "af854a3a-2127-422b-91ae-364da2661108"
    },
    {
      "url": "https://github.com/azure-rtos/usbx/security/advisories/GHSA-gg76-h537-xq48",
      "tags": [
        "Patch",
        "Third Party Advisory"
      ],
      "source": "af854a3a-2127-422b-91ae-364da2661108"
    }
  ],
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "type": "Secondary",
      "source": "security-advisories@github.com",
      "description": [
        {
          "lang": "en",
          "value": "CWE-191"
        }
      ]
    }
  ],
  "descriptions": [
    {
      "lang": "en",
      "value": "Azure RTOS USBX is a high-performance USB host, device, and on-the-go (OTG) embedded stack, that is fully integrated with Azure RTOS ThreadX. The case is, in [_ux_host_class_pima_read](https://github.com/azure-rtos/usbx/blob/master/common/usbx_host_classes/src/ux_host_class_pima_read.c), there is data length from device response, returned in the very first packet, and read by [L165 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L165), as header_length. Then in [L178 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L178), there is a “if” branch, which check the expression of “(header_length - UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE) > data_length” where if header_length is smaller than UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE, calculation could overflow and then [L182 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L182) the calculation of data_length is also overflow, this way the later [while loop start from L192](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L192) can move data_pointer to unexpected address and cause write buffer overflow. The fix has been included in USBX release [6.1.12](https://github.com/azure-rtos/usbx/releases/tag/v6.1.12_rel). The following can be used as a workaround: Add check of `header_length`: 1. It must be greater than `UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE`. 1. It should be greater or equal to the current returned data length (`transfer_request -> ux_transfer_request_actual_length`)."
    },
    {
      "lang": "es",
      "value": "Azure RTOS USBX es una pila embebida de host, dispositivo y on-the-go (OTG) USB de alto rendimiento, que está totalmente integrada con Azure RTOS ThreadX. El caso es que, en [_ux_host_class_pima_read](https://github.com/azure-rtos/usbx/blob/master/common/usbx_host_classes/src/ux_host_class_pima_read.c), se presenta una longitud de datos de la respuesta del dispositivo, devuelta en el primer paquete, y leída por [L165 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L165), como header_length. Entonces en [L178 code](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L178), se presenta una rama \"if\", que comprueba la expresión de \"(header_length - UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE) ) data_length\" donde si header_length es menor que UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE, el cálculo podría desbordarse y entonces [L182 code](https://github. com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L182) el cálculo de data_length también es desbordado, de esta forma el posterior [inicio del bucle while desde L192](https://github.com/azure-rtos/usbx/blob/082fd9db09a3669eca3358f10b8837a5c1635c0b/common/usbx_host_classes/src/ux_host_class_pima_read.c#L192) puede mover data_pointer a una dirección no esperada y causar un desbordamiento del buffer de escritura. La corrección ha sido incluida en USBX versión  [6.1.12](https://github.com/azure-rtos/usbx/releases/tag/v6.1.12_rel). Puede usarse lo siguiente como mitigación: Añadir la comprobación de \"header_length\": 1. Debe ser mayor que \"UX_HOST_CLASS_PIMA_DATA_HEADER_SIZE\". 1. Debe ser mayor o igual que la longitud de datos devuelta actualmente (\"transfer_request -) ux_transfer_request_actual_length\")"
    }
  ],
  "lastModified": "2026-06-17T04:58:05.203",
  "configurations": [
    {
      "nodes": [
        {
          "negate": false,
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:eclipse:threadx_usbx:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "FAB0B44A-E01F-4F4C-AFFF-A32FA32E775A",
              "versionEndExcluding": "6.1.12"
            }
          ],
          "operator": "OR"
        }
      ]
    }
  ],
  "sourceIdentifier": "security-advisories@github.com"
}