In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
fs\/proc\/task_mmu: fix make_uffd_wp_huge_pte() prot-update race<\/p>\n
Patch series “userfaultfd\/pagemap: pre-existing fixes”.<\/p>\n
These are pre-existing bug fixes that were carried at the front of the
\nuserfaultfd RWP working-set-tracking series up to v5 [1]. Per review
\nfeedback that fixes should not sit in the middle of a feature series, they
\nare split out and sent on their own; the RWP series is reposted rebased on
\ntop of this.<\/p>\n
All six were flagged by the Sashiko AI review of the RWP series and carry
\nindependent of RWP, apply to mm-new directly, and carry Cc: stable@.<\/p>\n
1: fs\/proc\/task_mmu: a missing huge_ptep_modify_prot_start() in
\n make_uffd_wp_huge_pte() can lose hardware Dirty\/Accessed updates
\n when PAGEMAP_SCAN write-protects a hugetlb PTE.<\/p>\n
2: fs\/proc\/task_mmu: pagemap_scan_hugetlb_entry() compares the range
\n against HPAGE_SIZE rather than the hstate page size, so it never
\n write-protects gigantic hugetlb pages.<\/p>\n
3: fs\/proc\/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an
\n unpopulated hugetlb range self-deadlocks — pagemap_scan_pte_hole()
\n calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb
\n vma lock for read, and hugetlb_change_protection() then takes it
\n for write. Install the marker inline instead.<\/p>\n
4: mm\/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp
\n on a device-private PMD permission downgrade, silently losing the
\n uffd-wp marker.<\/p>\n
5: userfaultfd: must_wait() applies pte_write() to a locklessly read
\n PTE without checking pte_present(), so swap\/migration entries
\n decode random offset bits and a thread can stay parked on a stale
\n fault.<\/p>\n
6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to
\n mk_vma_flags() unconditionally, an out-of-bounds write into the
\n single-word vma_flags_t on 32-bit. Build the mask from config-gated
\n per-mode masks so an unavailable bit is never materialised.<\/p>\n
This patch (of 6):<\/p>\n
make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by
\ncalling huge_ptep_modify_prot_commit() with a ptent snapshot that was
\nfetched without the corresponding huge_ptep_modify_prot_start(). The
\nstart helper is what atomically clears the entry so the kernel-owned
\nsnapshot stays consistent until the commit; without it, the hardware may
\nset Dirty or Accessed in the live PTE between the original read and the
\ncommit, and huge_ptep_modify_prot_commit() (whose generic implementation
\njust calls set_huge_pte_at()) then writes the stale snapshot back over the
\nlive hardware bits, losing the update.<\/p>\n
The non-hugetlb sibling make_uffd_wp_pte() does this correctly via
\nptep_modify_prot_start() \/ ptep_modify_prot_commit(). Mirror that pattern
\nfor the present-PTE branch. The migration case stays as-is — migration
\nentries are non-present, so there’s no hardware update to race against.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
fs\/proc\/task_mmu: fix make_uffd_wp_huge_pte() prot-update race<\/p>\n
Patch series “userfaultfd\/pagemap: pre-existing fixes”.<\/p>\n
These are <\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-6817","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/6817","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6817"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6817"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6817"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}