CVE-2024-36000

What it actually does

Missing acquisition of hugetlb_lock before calling hugetlb_cgroup_uncharge_folio_rsvd during resv map uncharge in concurrent UFFDIO_COPY operations on hugetlb pages, allowing a race between threads modifying the reservation map.

Why it matters to the business

Linux systems using huge pages may experience kernel instability, memory accounting errors, or crashes under concurrent memory operations, increasing downtime risk for high-performance or virtualized workloads.

How an attack unfolds

An attacker triggers concurrent hugetlb reservation map modifications via userfaultfd in a multi-threaded context, causing the uncharge path to execute without the required lock and potentially corrupting cgroup state or triggering assertions.

How to fix it

Update the Linux kernel to include commit 2c85ebc57b3e1817b6ce1a6b703928e113a90442 or later; rebuild and reboot systems using affected hugetlb code paths.

How to confirm the fix worked

Confirm the presence of commit 2c85ebc57b3e1817b6ce1a6b703928e113a90442 in the running kernel source or verify that lockdep_assert_held(&hugetlb_lock) is present before the uncharge call in mm/hugetlb.c.

Typical attack path

1. Identify or create a hugetlb-backed mapping accessible to attacker-controlled threads
2. Use userfaultfd to set up UFFDIO_COPY operations that race on the reservation map
3. Trigger two threads to modify the resv map simultaneously
4. Exploit the unlocked hugetlb_cgroup_uncharge_folio_rsvd path to induce inconsistent state

How to detect it

Review kernel logs for lockdep warnings or assertions mentioning hugetlb_lock and resv uncharge; inspect userfaultfd-related crash dumps for races in mm/hugetlb.c.

What your security team should do

• Prioritize kernel updates on systems with hugetlb and userfaultfd usage
• Monitor for kernel oops or lockdep warnings related to hugetlb_lock
• Restrict unprivileged userfaultfd access where feasible until patched