CVE-2025-38071

What it actually does

Failure to validate the return value from memblock_phys_alloc_range() causes a subsequent memblock_phys_free(0) call that releases the first 4 MiB of physical memory, resulting in kernel crash or memory corruption during early boot when contiguous free memory is below 4 MiB.

Why it matters to the business

Systems may fail to boot or experience unexpected crashes on low-memory configurations, leading to downtime, loss of availability, and potential data corruption on affected Linux kernels and downstream packages.

How an attack unfolds

An attacker with local access or control over boot parameters triggers the vulnerable allocation path on a system configured with limited contiguous physical memory below the 4 MiB threshold, causing the kernel to free incorrect memory regions and panic.

How to fix it

Upgrade to kernel versions containing commit 8c18c904d301ffeb33b071eadc55cd6131e1e9be or the equivalent fixed packages: kernel 4.1.15-2.mga5 (and matching fixed versions for kmod-broadcom-wl 6.30.223.271-5.mga5.nonfree, kmod-fglrx 15.200.1046-9.mga5.nonfree, kmod-nvidia304 304.128-5.mga5.nonfree, kmod-nvidia340 340.93-5.mga5.nonfree, kmod-nvidia-current 346.96-5.mga5.nonfree, and related Mageia 5 packages).

How to confirm the fix worked

Verify the presence of the return-value check in the memblock_phys_alloc_range() call site in the running kernel source or binary; confirm successful boot on low-memory test systems that previously triggered the panic.

Typical attack path

1. Configure or encounter a system with CONFIG_PHYSICAL_START=0x100000 and less than 4 MiB contiguous free memory at early boot.
2. Trigger the memblock_phys_alloc_range() call during kernel initialization.
3. Observe the unchecked zero return value passed to memblock_phys_free().
4. Kernel panics or corrupts low physical memory, denying service.

How to detect it

Inspect early kernel boot logs and dmesg output for panics or warnings referencing memblock_phys_alloc_range or memblock_phys_free failures; correlate with systems that failed to boot after low-memory conditions.

What your security team should do

• Prioritize patching all affected kernels and kmod packages to the listed fixed versions.
• Test boot behavior on representative low-memory hardware before wide deployment.
• Monitor kernel boot logs for allocation-related panics until patches are applied.