CVE-2024-35987: riscv: Fix loading 64-bit NOMMU kernels past the start of RAM
In the Linux kernel, the following vulnerability has been resolved:
riscv: Fix loading 64-bit NOMMU kernels past the start of RAM
commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear
mapping") added logic to allow using RAM below the kernel load address.
However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the
kernel load address. Since that range of memory corresponds to PFNs
below ARCH_PFN_OFFSET, mm initialization runs off the beginning of
mem_map and corrupts adjacent kernel memory. Fix this by restoring the
previous behavior for NOMMU kernels.
Security readout for executives and security teams
Plain-English summary
A Linux kernel defect can corrupt kernel memory when certain 64-bit RISC-V systems without an MMU load the kernel above the beginning of RAM. Successful triggering could compromise confidentiality, integrity, and availability. Exposure is configuration-specific rather than universal across Linux systems.
Executive priority
Prioritize prompt remediation for confirmed 64-bit RISC-V NOMMU deployments because kernel-memory corruption can cause complete system compromise or failure. First inventory architecture, NOMMU status, and kernel provenance; systems outside this configuration are not shown as exposed by the supplied sources.
Technical view
A linear-mapping change allowed RAM below the kernel load address. On 64-bit RISC-V NOMMU kernels, PAGE_OFFSET remains fixed at that load address, producing page-frame numbers below ARCH_PFN_OFFSET. Memory-management initialization can then access before mem_map and corrupt adjacent kernel memory. The fix restores the earlier NOMMU behavior.
Likely exposure
Potentially exposed assets are 64-bit RISC-V Linux systems using NOMMU and an affected kernel lineage, particularly where RAM exists below the kernel load address. MMU-enabled RISC-V and other architectures are not identified as affected by the supplied evidence. Exact distribution and device exposure requires vendor mapping.
Exploitation context
The CVSS 3.1 score is 8.4 with local access, low complexity, no privileges, and no user interaction. The supplied record does not show CISA KEV listing or other evidence of active exploitation. It also provides no public exploit evidence, so real-world exploitation status remains unconfirmed.
Researcher notes
The affected-version data is incomplete and internally awkward, including duplicate commit identifiers and an entry labelled "0." No CPEs or CWE classification are supplied. Use kernel ancestry and vendor advisories rather than version strings alone. Three stable-kernel fix commits are referenced, but the bundle does not map each commit to a specific release branch.
Mitigation direction
Upgrade to a vendor-supported kernel containing the applicable referenced stable fix.
Consult the device or distribution vendor for precise affected and fixed release mapping.
Where feasible, avoid the affected 64-bit RISC-V NOMMU kernel and memory-load configuration until updated.
Validation and detection
Confirm whether each asset uses 64-bit RISC-V with NOMMU.
Determine whether the deployed kernel includes the identified linear-mapping change.
Check whether the vendor kernel contains an applicable referenced stable fix.
After updating, test boot reliability and memory stability under the supported load configuration.
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-35987 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.