Skip to content
Fencer Intel
low —

GHSA-cx7h-h87r-jpgr json

The kstring integration in gix-attributes is unsound

published 2y ago modified 2mo ago also RUSTSEC-2024-0359

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

`gix-attributes` (in [`state::ValueRef`](https://github.com/Byron/gitoxide/blob/gix-attributes-v0.22.2/gix-attributes/src/state.rs#L19-L27)) unsafely creates a `&str` from a `&[u8]` containing non-UTF8 data, with the justification that so long as nothing reads the `&str` and relies on it being UTF-8 in the `&str`, there is no UB:

```rust // SAFETY: our API makes accessing that value as `str` impossible, so illformed UTF8 is never exposed as such. ```

The problem is that the non-UTF8 `str` **is** exposed to outside code: first to the `kstring` crate itself, which requires UTF-8 in its documentation and may have UB as a consequence of this, but also to `serde`, where it propagates to e.g. `serde_json`, `serde_yaml`, etc., where the same problems occur.

This is not sound, and it could cause further UB down the line in these places that can view the `&str`.

Patch / fix

  • crates.io gix-attributes 0.22.3

Is GHSA-cx7h-h87r-jpgr 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 Fencer

Affected packages

ecosystem package affected fixed in
crates.io gix-attributes
<0.22.3
>=0.0.0-0, <0.22.3
0.22.3

Classification

Weakness
  • CWE-172 Improper Encoding or Decoding of Data

References

Sources

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.