# GHSA-f366-4rvv-95x2: Buffer overflow in deprecated USB HALs and stack overflow in USB enumeration

> An attacker can trigger buffer or stack overflows in deprecated USB HALs or via excessive device enumeration, potentially causing code execution or crashes.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 2 Oct 2020

## What is GHSA-f366-4rvv-95x2?

GHSA-f366-4rvv-95x2 is a memory corruption vulnerability in cryptoauthlib, published on 2 Oct 2020. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.

### Official description

### Impact
1) If an application is making use of the deprecated kit protocol HALs as the communication channel to the target device an attacker can masquerade as a device and return malformed packets of arbitrary length which the protocol stack will write to the stack. HALs intended for production use are unaffected (I2C, SWI, & SPI) as well as the hidapi HAL (hal_all_platforms_kit_hidapi.c).

2) The hidapi HAL can be made to overrun the application stack by attaching more than 10 (real or virtual) devices likely resulting in an application crash as this does not allow arbitrary data to be written to the stack.

### Patches
USB kit enumeration has been patched in v3.2.3 for the hidapi HAL (hal_all_platforms_kit_hidapi.c).

### Removal of deprecated HALs
Deprecated usb kit HALs have been removed in v3.2.3.

### Workarounds
This vulnerability is limited to users of the kit protocol which is used with Microchip kits and kit firmware to bridge communication from USB-HID to I2C or SWI. It is not expected that kits would be used in an production environment. This is an optional component for users as well so they can always compile the library without the usb support option.

### Special python packaging notes
The python package for cryptoauthlib uses date codes for identifying versions. The patched version for python packages is 20200912

### References
Please see [Microchip PSIRT](https://www.microchip.com/design-centers/embedded-security/how-to-report-potential-product-security-vulnerabilities) for Microchip's security policy and reporting procedures

### Credits
Special thanks to Ruben Santamarta of [IOActive](https://blogs.ioactive.com/) for reporting

## Which versions are affected by GHSA-f366-4rvv-95x2?

2 open source packages ship an affected version, including cryptoauthlib.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `cryptoauthlib` | PyPI | All versions | 20200912 |
| `cryptoauthlib` | PyPI | All versions | 20200912 |

## How do I fix GHSA-f366-4rvv-95x2?

Upgrade cryptoauthlib to 20200912 or later.

## Is GHSA-f366-4rvv-95x2 being exploited?

There is no known exploitation of GHSA-f366-4rvv-95x2 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-f366-4rvv-95x2 and fix it if it is affected.

What it is: GHSA-f366-4rvv-95x2 is a memory corruption vulnerability in cryptoauthlib, published on 2 Oct 2020. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.
Exploitation: There is no known exploitation of GHSA-f366-4rvv-95x2 in the wild and no public exploit code.

Affected packages and fixed versions:
- cryptoauthlib (PyPI): affected all versions; fixed in 20200912
- cryptoauthlib (PyPI): affected all versions; fixed in 20200912

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-f366-4rvv-95x2/ (Markdown: https://insights.sbomify.com/GHSA-f366-4rvv-95x2/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-f366-4rvv-95x2

---
From sbomify Insights: https://insights.sbomify.com/GHSA-f366-4rvv-95x2/
Summaries are generated and may contain mistakes; the official description above is the record.
