CVE-2024-35875: x86/coco: Require seeding RNG with RDRAND on CoCo systems
In the Linux kernel, the following vulnerability has been resolved:
x86/coco: Require seeding RNG with RDRAND on CoCo systems
There are few uses of CoCo that don't rely on working cryptography and
hence a working RNG. Unfortunately, the CoCo threat model means that the
VM host cannot be trusted and may actively work against guests to
extract secrets or manipulate computation. Since a malicious host can
modify or observe nearly all inputs to guests, the only remaining source
of entropy for CoCo guests is RDRAND.
If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole
is meant to gracefully continue on gathering entropy from other sources,
but since there aren't other sources on CoCo, this is catastrophic.
This is mostly a concern at boot time when initially seeding the RNG, as
after that the consequences of a broken RDRAND are much more
theoretical.
So, try at boot to seed the RNG using 256 bits of RDRAND output. If this
fails, panic(). This will also trigger if the system is booted without
RDRAND, as RDRAND is essential for a safe CoCo boot.
Add this deliberately to be "just a CoCo x86 driver feature" and not
part of the RNG itself. Many device drivers and platforms have some
desire to contribute something to the RNG, and add_device_randomness()
is specifically meant for this purpose.
Any driver can call it with seed data of any quality, or even garbage
quality, and it can only possibly make the quality of the RNG better or
have no effect, but can never make it worse.
Rather than trying to build something into the core of the RNG, consider
the particular CoCo issue just a CoCo issue, and therefore separate it
all out into driver (well, arch/platform) code.
[ bp: Massage commit message. ]
Security readout for executives and security teams
Plain-English summary
This flaw affects x86 confidential-computing guests that depend on RDRAND for trustworthy randomness during startup. If RDRAND fails, a hostile host could influence the remaining entropy sources, potentially weakening cryptographic secrets or manipulating protected computation. The kernel fix refuses to boot safely when adequate RDRAND seeding is unavailable.
Executive priority
Treat this as a high-priority hardening update for x86 confidential-computing workloads, especially those protecting valuable keys or regulated data. It is not evidence of widespread active exploitation. Patch through supported vendor channels promptly, while prioritizing exposed CoCo guests over ordinary Linux hosts not matching the stated threat model.
Technical view
Before the fix, an x86 CoCo guest could continue booting after RDRAND failure despite lacking another host-independent entropy source. The correction requires 256 bits of RDRAND output during boot and panics if collection fails or RDRAND is unavailable. The supplied CVSS 3.1 score is 8.4, with high confidentiality, integrity, and availability impact.
Likely exposure
Exposure is concentrated in Linux running as an x86 confidential-computing guest, particularly during early boot. Conventional systems outside the CoCo threat model are not identified as the primary concern. The bundle lists affected Linux releases, but its flattened version data does not clearly express intervals or distribution backports; verify exact kernel status with the supplier.
Exploitation context
No active exploitation is established: the bundle marks this CVE as absent from KEV and provides no exploitation report. The relevant threat is a malicious or compromised VM host combined with absent or faulty RDRAND during guest boot. The evidence does not show that ordinary remote attackers can trigger the condition.
Researcher notes
The security boundary depends on RDRAND being the guest's remaining host-independent entropy source. The fix intentionally converts unsafe startup into fail-closed behavior, creating possible availability impact when RDRAND is unavailable. Exact affected-version interpretation is incomplete in the supplied flattened data; the four stable commits and downstream vendor records should be used for build-level confirmation.
Mitigation direction
Update affected CoCo guests to a supported kernel containing the applicable cited stable fix or vendor backport.
Confirm the confidential-computing platform provides functioning RDRAND to every protected x86 guest.
Consult the Linux distribution or platform vendor for exact fixed package versions.
Prioritize sensitive guests that generate cryptographic keys or secrets during boot.
Validation and detection
Inventory x86 Linux confidential-computing guests and record their kernel package, build, and boot configuration.
Map each deployed kernel to a cited stable fix or a documented downstream backport.
Confirm RDRAND is available to affected guests and investigate any related boot or hardware errors.
Review vendor advisories because the supplied version list does not define reliable distribution-specific fixed boundaries.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-35875 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.