Headline
GHSA-cx7h-h87r-jpgr: The kstring integration in gix-attributes is unsound
gix-attributes
(in state::ValueRef
) 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:
// 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
.
gix-attributes (in state::ValueRef) 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:
// 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.
References
- Byron/gitoxide#1460
- rustsec/advisory-db@884aaa1
- https://rustsec.org/advisories/RUSTSEC-2024-0359.html