advisory-db
advisory-db copied to clipboard
Soundness issues in crates for self-referential structs
Most crates that allow self-referential structs are unsound. See https://github.com/Voultapher/self_cell/pull/41 for a list of crates and issues.
We have advisories for Ourouboros (RUSTSEC-2023-0042) and owning-ref (https://rustsec.org/advisories/RUSTSEC-2022-0040.html), we should cover the remaining crates with advisories as well.
@Manishearth hopefully yoke
isn't impacted?
AIUI no. yoke
does have potential unsoundness based on some yet-to-be-figured-out opsem rules (and can be fixed with yet-to-be-figured-out APIs). I'm mostly planning on waiting that out, it's tracked in https://github.com/unicode-org/icu4x/issues/2095. There is a way for us to avoid that potential unsoundness today; but that would require giving up an API that I would rather not do yet. Furthermore that potential unsoundness is only present for certain kinds of uses of Yoke.
In general yoke exposes a more limited form of self-reference and is not as susceptible to the issues found in general self-ref crates.
Personally because these rules are still in flux I do not consider "fails miri" to in and of itself be an indication of unsoundness, fwiw. I expect that when the time comes to actually start exploiting the UB surface provided by stacked borrows[^1]; the opsem group will have also provided sufficient APIs to do things like this in ways they can guarantee are sound.
That said, yoke does not currently trip miri anyway.
cc @CAD97
[^1]: Though it's likely stacked borrows itself is going away and being replaced by tree borrows; which is an example of what I mean by these things still being in flux!
is it correct to say selfref
is not affected by this?