> It does not have a CVE associated since the issue was spotted within Rust stdlib first. That is blatant nonsense. Even if the vulnerability is similar or ide

> It does not have a CVE associated since the issue was spotted within Rust stdlib first. That is blatant nonsense. Even if the vulnerability is similar or identical, CVEs are submitted for every affected project. If it were not there would not have been a bounds-check CVE in the last 35 years. The only situation in which that might not be the case is if the vulnerability is in an upstream library, but even then you often get a CVE in both upstream and downstream (or a CVE shared between multiple products) e.g. the libwebp 0-day from late 2023 got a CVE for Apple’s various OS (two in fact) and a shared CVE for libwebp and chrome, mozilla used that as their upstream CVE in emitting a security advisory. The CVE-2022-21658 only covers the Rust standard library, that is not upstream of either libc++ or libstdc++, and neither fix references it anyway. The GP might have gone a hair too far in saying that C++ “does not consider it a problem at all”, but they’re correct that C++ compiler/stdlib maintainers do not consider it a vulnerability.