CVE-2024-51729

What it actually does

Unbounded memory corruption or information leak when copy_user_gigantic_page receives a fault address that is not huge-page aligned, because hugetlb_wp passes the raw fault address through copy_user_large_folio.

Why it matters to the business

Linux systems using huge pages may experience kernel crashes, silent data corruption, or unauthorized disclosure of kernel or user memory, increasing downtime and compliance risk until kernels are updated.

How an attack unfolds

An attacker maps a gigantic huge page, triggers a write fault at an offset that is not aligned to the huge-page size, and causes the kernel to invoke copy_user_gigantic_page with the misaligned address, resulting in out-of-bounds memory operations.

How to fix it

Upgrade the Linux kernel to the commit cb12d61361ce769672c7c7bd32107252598cdd8b (or later stable equivalent) that enforces huge-page alignment via addr_hint; rebuild and reboot all affected hosts.

How to confirm the fix worked

Confirm the running kernel contains the aligned-address change in mm/hugetlb.c; run regression tests that exercise hugetlb_wp with misaligned faults and verify no corruption occurs.

Typical attack path

1. Map a gigantic huge page in a user process
2. Trigger a write fault at a non-huge-page-aligned address inside hugetlb_wp
3. copy_user_large_folio passes the raw address to copy_user_gigantic_page
4. Unaligned copy performs out-of-bounds read or write
5. Attacker observes leaked data or induces memory corruption for further exploitation

How to detect it

Search kernel logs for hugetlb, copy_user_gigantic_page, and page-fault entries that precede crashes or unexpected memory-access violations; correlate with processes using MAP_HUGETLB.

What your security team should do

• Prioritize kernel upgrades on systems that enable gigantic huge pages
• Add hugetlb-related kernel oops and page-fault anomalies to alerting
• Re-test applications that rely on huge-page allocations after patching