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
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When activating the non-default feature serialize, most structs implement serde::Deserialize without sufficient validation. This allows breaking invariants in safe code, leading to: Undefined behavior in asstring() methods (which use std::str::fromutf8unchecked() internally). Panics due to failed assertions. See https://github.com/gz/rust-cpuid/issues/43.
Recommended action: Upgrade to 9.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in the raw-cpuid crate before 9.1.1 for Rust. If the serialize feature is used (which is not the the default), a Deserialize operation may lack sufficient validation, leading to memory corruption or a panic.
Recommended action: Upgrade to 9.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
VendorInfo::asstring(), SoCVendorBrand::asstring(), and ExtendedFunctionInfo::processorbrandstring() construct byte slices using std::slice::fromrawparts(), with data coming from #[repr(Rust)] structs. This is always undefined behavior. This flaw has been fixed in v9.0.0, by making the relevant structs #[repr(C)].
Recommended action: Upgrade to 9.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
nativecpuid::cpuidcount() exposes the unsafe cpuidcount() intrinsic from core::arch::x86 or core::arch::x8664 as a safe function, and uses it internally, without checking the safety requirement: The CPU the program is currently running on supports the function being called. CPUID is available in most, but not all, x86/x8664 environments. The crate compiles only on these architectures, so others are unaffected. This issue is mitigated by the fact that affected programs are expected to crash deterministically every time. The flaw has been fixed in v9.0.0, by intentionally breaking compilation when targeting SGX or 32-bit x86 without SSE. This covers all affected CPUs.
Recommended action: Upgrade to 9.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.