GHSA-h6xm-c6r4-vmwf json
Unsound usages of `u8` type casting in spl-token-swap
published last yr. modified last yr. also RUSTSEC-2024-0426
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
The library provides a safe public API `unpack` to cast `u8` array to arbitrary types, which can cause to undefined behaviors. The length check of array can only prevent out-of-bound access on the return type. However, it can't prevent misaligned pointer when casting `u8` pointer to a type aligned to larger bytes. For example, if we assign `u16` to `T`, **misaligned raw pointer dereference** could happen and cause to panic. Even if we pass the type aligned to same byte as `u8` (e.g., `bool`), it could construct a illegal type since `bool` can only have 0 or 1 as bit patterns, which is also an undefined behavior. The further exploits of the bug here are still not clear, so we would report this issue as unsound.
The details of PoC to reproduce undefined behavior are provided in the [issue](https://github.com/solana-labs/solana-program-library/issues/5243).
Is GHSA-h6xm-c6r4-vmwf in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | spl-token-swap | <=3.0.0 >=0.0.0-0 |
no fix listed |
References
Sources
- GitHub Advisory GHSA-h6xm-c6r4-vmwf
- OSV RUSTSEC-2024-0426
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.