Re: [PATCH 00/10] mm: various (urgent?) fixes

["David Hildenbrand (Arm)" <david@kernel.org>]

On 10/16/26 09:15, Muchun Song wrote:
> 
> 
>> On Oct 16, 2026, at 00:07, David Hildenbrand (Arm) <david@kernel.org> wrote:
>>
>> Hi,
>>
>> here are various MM fixes. The majority was reported by Josef at
>> Anthrophic, the remainder was found while reviewing/overhauling them.
>>
>> Two issues/fixes reported are not included, as we are discussing
>> (better) alternatives on the list already.
>>
>> I left most of the original commit messages as schloppy as they are: I
>> don't particularly care as long as the code is in good shape and as long as
>> they are not actively wrong. But I (and Mike) could not be stopped from
>> overhauling at least some of them.
>>
>> While I don't think there is anything too critical in here, I think this
>> is a good opportunity to see how fast we can get pre-screened/pre-reviewed
>> fixes upstream that might be security-related.
>>
>> The majority are hugetlb + uffd issues, that are not actually that
>> relevant for most installations. But all things that should just get
>> fixed. Some uffd fixes need proper follow ups to fix some more of the
>> root causes of leftover UFFD PTE bits (or proof that there are none
>> remaining).
>>
>> I ran some MM selftests and nothing popped up.
>>
>> So let's try to get these upstream in a timely fashion.
>>
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>> ---
>> David Hildenbrand (Arm) (4):
>>      mm/hugetlb: fix use-after-free in hugetlb_mfill_atomic_pte()
>>      mm/hugetlb: tolerate uffd bits set without uffd for PROT_NONE PTEs
>>      mm/hugetlb: tolerate UFFD_WP markers outside uffd-wp VMAs
>>      mm/mremap: fix calling fixup_hugetlb_reservations() on the wrong VMA
>>
>> Josef Bacik (6):
>>      mm/vma: don't leak the commit charge on mmap failure
>>      mm/hugetlb: fix use-after-free of a new anon folio
>>      mm/hugetlb: unmap the page where the other VMA maps it
>>      mm/hugetlb: don't clear the resv_map of a VMA whose lock is held
>>      mm/hugetlb: fix endless write fault on a leftover uffd bit
>>      mm/hugetlb: don't leave a uffd-wp marker when zapping an RWP entry
> 
> HugeTLB is really nasty, while no new features are landing, we have a steady
> stream of bug fixes coming in.

Yes, and so far it's mostly due to:

* PMD table sharing
* Reservation handling
* Userfaultfd

Which is no surprise given how people already felt about most of these features
in the past :)

-- 
Cheers,

David