CVE-2024-36943

What it actually does

Race condition in make_uffd_wp_pte() allows loss of young/dirty PTE bits when another thread accesses or dirties the page between ptep_get and ptep_modify_prot_start, due to non-atomic sequence instead of atomic get-and-clear.

Why it matters to the business

Memory tracking inaccuracies in userfaultfd-dependent workloads may cause subtle data loss, incorrect page fault handling, or application instability on affected Linux kernels.

How an attack unfolds

An attacker with local access races concurrent memory operations against a target process using userfaultfd write-protect to corrupt PTE state; the window is closed by the atomic pattern in the fix.

How to fix it

Upgrade the Linux kernel to a version containing commit 74b3d66f91d9f539f99faad74d796fa9a389a015 or later; rebuild and reboot all affected systems.

How to confirm the fix worked

Confirm kernel source contains the corrected ptep_modify_prot_start pattern; run pagemap and userfaultfd regression tests; verify no older vulnerable kernels remain in the boot chain.

Typical attack path

1. Locate a process using userfaultfd write-protect on shared memory
2. Time a read or write from a second thread to overlap the vulnerable PTE sequence
3. Observe or induce loss of young/dirty information leading to incorrect page handling

How to detect it

Review kernel logs and process memory maps for unexpected page fault patterns or missing dirty-bit updates around userfaultfd operations; no public exploitation artifacts exist.

What your security team should do

• Prioritize kernel updates on systems running userfaultfd or pagemap-dependent services
• Monitor vendor advisories for backported fixes in distribution kernels
• Test memory-intensive workloads after patching to confirm stability