Add unsound advisory for lockfree

[tooson9010-spec]

Affected crate(s)

• lockfree (601,950 recent downloads per crates.io)

Links to upstream issue(s) or PR(s)

https://gitlab.com/bzim/lockfree/-/issues/7

Severity

Two independent soundness problems, both reachable from safe Rust and confirmed with sanitizers. Map::into_iter drops the caller-supplied hasher before committing with mem::forget(self), so a panicking H::drop leaves the unwinding Map to drop it again — use-after-free / double-free under AddressSanitizer, with an empty map. SharedIncin::clear writes mem::uninitialized::<Arc<_>>() into a live field, which Miri reports as undefined behavior with no panic or concurrency involved; the macro is instantiated five times. No fixed release.

Checklist

• Advisory filename(s) starts with RUSTSEC-0000-0000 as the ID
• date field is set to the public disclosure date
• Contains a concise and descriptive title after advisory metadata
• Asked maintainer(s) if publishing an advisory is appropriate (reported two weeks ago, no response; the crate has had no release since 2018 and an August 2024 unmaintained inquiry also went unanswered)

[djc]

Commented in the upstream issue and mentioned the maintainer.

If there's been no change in a week, feel free to ping me.

[tooson9010-spec]

@djc
Thanks for reaching out to the maintainer directly.

I'll ping you in a week if there's no change.

[tooson9010-spec]

@djc
Following up as you suggested. No response upstream after a week.
The crate hasn't been updated in almost eight years, and it's still at 721k recent downloads.
Let me know how you'd like to proceed, and thanks again for reaching out to the maintainer.

[djc]

Sent a private email to the maintainer. Let's give it one more week.

[tooson9010-spec]

@djc
Thanks for following up with them directly. I'll check back in a week.

[tooson9010-spec]

@djc
While we wait on bzim, I found a similar issue in owned-alloc, same
GitLab account, also last released ~8 years ago and at a similar download
volume.

OwnedAlloc::drop_in_place destroys the value before mem::forget, so a
panicking Drop leaves the container to free the same allocation twice —
double free and UAF, confirmed under ASAN. Reported as owned-alloc#1.

That one may be unmaintained too. How would you like to handle it?

[djc]

That one may be unmaintained too. How would you like to handle it?

Submit a separate PR for an advisory? If the maintainer continues to be unresponsive we can cut the waiting period short.

[tooson9010-spec]

@djc
Thanks! Opened owned-alloc#1 yesterday and submitted the advisory as #3205. Same maintainer and account as lockfree, so I doubt the response will differ, and I noted the report date in the PR so you can judge the waiting period.