Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Three removal and replacement paths destroy an initialized value before committing the metadata change that removes it. Destruction runs `T::drop()`, which is user code and may panic. If it does, the commit is skipped and the container still claims ownership of the already-destroyed value, so its own destructor drops that value a second time. `Stack::pop` drops the top value before reducing `next_ofs`. `Stack`'s destructor pops in a loop, so an unchanged `next_ofs` re-drops the same value. `Fifo::pop_front` (via `pop_front_inner`) drops the front value before advancing `read_pos`. An unchanged `read_pos` still points at the destroyed value. `Value::replace_stable` drops the existing value before writing the replacement. If the destructor panics the replacement is never written, but the backing storage still holds the old value's metadata. This is separate from RUSTSEC-2021-0033, which covered a clone panic on insertion in `push_cloned` and was fixed in 0.6.1. Impact A heap-owning…
Recommended action: Upgrade to 0.8.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected versions of stackdst used a pushinner function that increased the internal length of the array and then called val.clone(). If the val.clone() call panics, the stack could drop an already dropped element or drop uninitialized memory. This issue was fixed in 2a4d538 by increasing the length of the array after elements are cloned.
Recommended action: Upgrade to 0.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected versions of stackdst used a pushinner function that increased the internal length of the array and then called val.clone(). If the val.clone() call panics, the stack could drop an already dropped element or drop uninitialized memory. This issue was fixed in 2a4d538 by increasing the length of the array after elements are cloned.
Recommended action: Upgrade to 0.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.