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 as_string() methods (which use std::str::from_utf8_unchecked() internally). Panics due to failed assertions. See https://github.com/gz/rust-cpuid/issues/43.
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.
VendorInfo::as_string(), SoCVendorBrand::as_string(), and ExtendedFunctionInfo::processor_brand_string() construct byte slices using std::slice::from_raw_parts(), 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)].
native_cpuid::cpuid_count() exposes the unsafe __cpuid_count() intrinsic from core::arch::x86 or core::arch::x86_64 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/x86_64 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 …