CVE-2024-45022

What it actually does

The __vmap_pages_range_noflush() function assumes uniform page shifts in its pages** argument, but vm_area_alloc_pages() with __GFP_NOFAIL can mix high-order and order-0 pages after fallback, producing incorrect virtual mappings and memory corruption.

Why it matters to the business

Linux systems may experience kernel memory corruption, crashes, or data integrity loss during memory allocation operations that trigger high-order fallback paths, increasing operational risk until kernels are updated.

How an attack unfolds

An attacker or workload invokes kvmalloc or __vmalloc_node_range with __GFP_NOFAIL and GFP flags under vmap_allow_huge=true conditions; when high-order allocation fails, the mixed page shifts cause __vmap_pages_range_noflush to apply the wrong shift (e.g., 21 for 2M), resulting in corrupted mappings that an attacker can leverage for further kernel exploitation.

How to fix it

Upgrade Linux kernel to version 6.1.107 or later, or apply the fix at commit fd1ffbb50ef4da5e1378a46616b6d7407dc795da; remove the high-order fallback logic inside vm_area_alloc_pages so that __vmalloc_node_range_noprof handles order-0 retry itself.

How to confirm the fix worked

Verify running kernel version is at or above the fixed release; confirm absence of the fallback code path in vm_area_alloc_pages via source inspection or kernel symbol checks; test allocation paths with __GFP_NOFAIL under memory pressure to ensure uniform page shifts.

Typical attack path

1. Trigger allocation path that requests high-order pages with __GFP_NOFAIL
2. Force high-order allocation failure to activate fallback to order-0 pages
3. Invoke vmap_pages_range_noflush which passes mixed-shift array
4. Observe or exploit resulting incorrect page mappings and memory corruption

How to detect it

Review kernel logs for page mapping errors, oops, or corruption traces during vmalloc operations; inspect dmesg for vmap or allocation failure messages that coincide with mixed page shifts.

What your security team should do

• Apply kernel updates to 6.1.107 or equivalent fixed versions immediately on all affected systems
• Monitor for kernel oops or corruption reports in logs during memory-intensive workloads
• Restrict use of __GFP_NOFAIL allocations where possible until patched