Publish a new v0.8.x (not v0.9.x) of crossbeam-epoch?

[tatsuya6502]

Hi. First and foremost thanks for making crossbeam crates!

I have a question and a request about crossbeam-epoch:

1. Question: Is crossbeam-epoch v0.8.2 affected by crossbeam-utils CVE-2022-23639?
2. Request: Is it possible to publish a new v0.8.x (not v0.9.x) version of crossbeam-epoch that depends on a newer crossbeam-utils having the fix for CVE-2022-23639?

As for 1., My answer is no (not affected), because I believe crossbeam-epoch v0.8.2 does not use crossbeam_utils::AtomicCell. But I still want to check with the crossbeam creators if I am correct.

Here is what I did to confirm it:

• Vulnerable to CVE-2022-23639? moka-rs/moka#162 (comment)

As for 2., currently I cannot update the crossbeam-epoch dependency in my crate (moka) from v0.8.2 to v0.9.x, because I found doing so makes a known segmentation fault issue in moka to occur ~15% more often on Linux x86_64. I am trying to fix the issue, but it is taking time to isolate the root cause. (I found the issue in September 2021 in my testing environment. I have a workaround in moka to reduce the chance to occur, so no users have reported the issue so far)

Meanwhile, GitHub Dependabot is creating alerts about CVE-2022-23639 for moka users. So I am getting more inquiries from users now.

Although crossbeam-epoch v0.8.2 seems not affected, Dependabot cannot see it. It will make Dependabot happy if the crossbeam-utils dependency is upgraded to a fixed version.

I am willing to work on this if you need any help. One minor issue would be that we need to find the commit used to publish crossbeam-epoch v0.8.2. There is no git tag for it. I was able to extract the source files of v0.8.2 by using cargo vendor sub-command, so I could compare the files against the repository with a given revision checked-out.

[taiki-e]

Question: Is crossbeam-epoch v0.8.2 affected by crossbeam-utils CVE-2022-23639?

epoch doesn't use AtomicCell, so it does not affect by GHSA-qc84-gqf4-9926.

---

Request: Is it possible to publish a new v0.8.x (not v0.9.x) version of crossbeam-epoch that depends on a newer crossbeam-utils having the fix for GHSA-qc84-gqf4-9926?

I think I have already said my thoughts on this in #781 (comment).

For the same reason as #749 (comment), we no longer maintain 0.7.x releases. So no backport to 0.7.x has been made. However, if someone sends a backport to the 0.7 branch and also fixes the CI-related issues (which we expect will probably occur), then we can accept it and release a new 0.7.x release.

---

As for 2., currently I cannot update the crossbeam-epoch dependency in my crate (moka) from v0.8.2 to v0.9.x, because I found doing so makes a known segmentation fault issue in moka to occur ~15% more often on Linux x86_64. I am trying to fix the issue, but it is taking time to isolate the root cause. (I found the issue in September 2021 in my testing environment. I have a workaround in moka to reduce the chance to occur, so no users have reported the issue so far)

Reducing MAX_OBJECTS makes it more likely to trigger any potential data races. So reverting #552 may reduce the occurrence of SIGSEGV. (Of course, that does not mean that the underlying bug is fixed.)

I'm not sure if there are any other changes that have affected it.

---

I am willing to work on this if you need any help. One minor issue would be that we need to find the commit used to publish crossbeam-epoch v0.8.2. There is no git tag for it. I was able to extract the source files of v0.8.2 by using cargo vendor sub-command, so I could compare the files against the repository with a given revision checked-out.

Thanks! The v0.7 branch is for epoch v0.8, utils v0.7, etc.

[tatsuya6502]

Thank you so much for quickly answering my questions! It was really nice to me and the users of my crate to know crossbeam-epoch v0.8 is not affected.

I am closing this issue, because:

• All my questions were answered.
• I found and fixed the root cause of segmentation fault issue in moka crate:
  • There was a code path in moka to allow a race condition and it will result to drop the same Arc pointer more than once using crossbeam-epoch's Guard::defer_unchecked method.
• Since the issue was fixed, I upgraded moka's crossbeam-epoch dependency to v0.9.9.
  • So I do not need to create and publish the new crossbeam-epoch v0.8.x version anymore.

Thanks!