CVE-2024-35987

What it actually does

The flaw causes out-of-bounds writes before the start of mem_map during mm initialization on RISC-V NOMMU kernels when the kernel load address is higher than the start of RAM, because PFNs below ARCH_PFN_OFFSET are referenced and PAGE_OFFSET is fixed to the kernel load address.

Why it matters to the business

Embedded or specialized RISC-V deployments without an MMU may suffer boot-time kernel memory corruption or crashes, reducing availability of affected devices and requiring urgent updates across fleets that use 64-bit NOMMU configurations.

How an attack unfolds

An attacker supplies a kernel image or boot parameters that place a 64-bit NOMMU RISC-V kernel past the start of physical RAM; on boot the linear mapping logic from commit 3335068f8721 then indexes below ARCH_PFN_OFFSET, causing mm initialization to corrupt adjacent kernel memory structures.

How to fix it

Update to the Linux kernel commit b008e327fa570aca210f98c817757649bae56694 or any later stable release that restores the previous NOMMU linear-mapping behavior; rebuild and deploy the fixed kernel to all affected RISC-V NOMMU systems.

How to confirm the fix worked

Confirm the running kernel contains commit b008e327fa570aca210f98c817757649bae56694, then boot test images loaded past the start of RAM on RISC-V NOMMU hardware and verify that mem_map initialization no longer writes before its base address.

Typical attack path

1. Obtain ability to influence kernel image placement or boot loader arguments on target RISC-V NOMMU hardware
2. Load the kernel at an address higher than the beginning of RAM
3. Trigger boot so that mm initialization runs and performs writes before mem_map
4. Leverage resulting memory corruption for denial of service or further kernel compromise

How to detect it

Inspect kernel boot logs and early dmesg output on RISC-V NOMMU systems for signs of mem_map corruption, invalid PFN references, or panics during linear mapping setup; correlate with boot loader records showing kernel placement relative to physical RAM start.

What your security team should do

• Prioritize patching all RISC-V NOMMU kernels to the fixed commit within the next maintenance window
• Review boot configurations to ensure kernel load addresses align with RAM start until patches are applied
• Add RISC-V NOMMU boot tests that load kernels past RAM start to CI pipelines