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

David Hildenbrand (Arm) posted 10 patches 1 week, 1 day ago
mm/hugetlb.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++--------------
mm/mremap.c  |  2 +-
mm/vma.c     | 11 ++++++----
3 files changed, 62 insertions(+), 21 deletions(-)
[PATCH 00/10] mm: various (urgent?) fixes
Posted by David Hildenbrand (Arm) 1 week, 1 day ago
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

 mm/hugetlb.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++--------------
 mm/mremap.c  |  2 +-
 mm/vma.c     | 11 ++++++----
 3 files changed, 62 insertions(+), 21 deletions(-)

---

base-commit: 0fcb05b72344f40806cbe810de8872f1698bf053

change-id: 20261015-urgent_fixes-7112629346eb

--

Cheers,

David
Re: [PATCH 00/10] mm: various (urgent?) fixes
Posted by Muchun Song 1 week ago

> 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.

Thanks,
Muchun

> 
> mm/hugetlb.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++--------------
> mm/mremap.c  |  2 +-
> mm/vma.c     | 11 ++++++----
> 3 files changed, 62 insertions(+), 21 deletions(-)
> 
> ---
> 
> base-commit: 0fcb05b72344f40806cbe810de8872f1698bf053
> 
> change-id: 20261015-urgent_fixes-7112629346eb
> 
> --
> 
> Cheers,
> 
> David
> 
Re: [PATCH 00/10] mm: various (urgent?) fixes
Posted by David Hildenbrand (Arm) 1 week ago
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