CVE-2026-72175

This is a data-integrity bug, not a traditional memory-safety violation — and that's what makes it dangerous. The function `make_uffd_wp_huge_pte()` performs a non-atomic read-modify-write on a live page-table entry. The kernel reads a snapshot of the PTE, but between that read and the writeback, the CPU's memory-management hardware can independently set the Dirty and Accessed bits in the live entry. When the stale snapshot is written back, those hardware updates are permanently discarded. No crash occurs. No error is signaled. The kernel simply becomes ignorant of memory that has been accessed or modified. The consequences are subtle but corrosive. Dirty and Accessed bits feed directly into page-reclaim decisions, copy-on-write semantics, and memory accounting. If the kernel believes a hugetlb page is clean and untouched when it has actually been accessed, it will make incorrect eviction and fork-sharing decisions. Over time, this produces silent degradation: pages remain in memory past their useful life, copy-on-write faults fire unexpectedly, and the kernel gradually becomes a worse custodian of its own memory. You'll never see a crash from this — only unexplained performance regressions or puzzling OOM events at workload sizes that should have been fine. The fix mirrors what the non-hugetlb path already does correctly: use the `huge_ptep_modify_prot_start() / huge_ptep_modify_prot_commit()` pair instead of directly calling the commit helper. This atomicity pattern exists because the CPU can modify PTE bits between any two instructions — the kernel learned this lesson expensively in THP migration, KSM merging, and speculative page fault handling, each of which had variants of the same mistake. This bug has almost certainly existed since the hugetlb userfaultfd path was merged, meaning long-running workloads may have accumulated corrupted memory accounting without any diagnostic trace. The CVSS score of 7.1 measures acute damage and misses the slow-burn systemic corrosion this class of bug produces. For production systems using hugetlb with userfaultfd enabled — particularly databases and HPC workloads — the priority is getting the patch deployed, but you should also instrument page-reclaim behavior for anomalies: pages staying in memory longer than their reference bits warrant, unexpected COW faults, or fork children holding pages they shouldn't share. These are symptoms that would surface this class of failure in production, but only if you're looking for them.

Reviewed through automated stages and approved by a human before publication.