The patch titled Subject: mm/mempolicy: correctly update prev when policy is equal on mbind has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-mempolicy-correctly-update-prev-when-policy-is-equal-on-mbind.patch
This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches...
This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days
------------------------------------------------------ From: Lorenzo Stoakes lstoakes@gmail.com Subject: mm/mempolicy: correctly update prev when policy is equal on mbind Date: Sun, 30 Apr 2023 16:07:07 +0100
The refactoring in commit f4e9e0e69468 ("mm/mempolicy: fix use-after-free of VMA iterator") introduces a subtle bug which arises when attempting to apply a new NUMA policy across a range of VMAs in mbind_range().
The refactoring passes a **prev pointer to keep track of the previous VMA in order to reduce duplication, and in all but one case it keeps this correctly updated.
The bug arises when a VMA within the specified range has an equivalent policy as determined by mpol_equal() - which unlike other cases, does not update prev.
This can result in a situation where, later in the iteration, a VMA is found whose policy does need to change. At this point, vma_merge() is invoked with prev pointing to a VMA which is before the previous VMA.
Since vma_merge() discovers the curr VMA by looking for the one immediately after prev, it will now be in a situation where this VMA is incorrect and the merge will not proceed correctly.
This is checked in the VM_WARN_ON() invariant case with end > curr->vm_end, which, if a merge is possible, results in a warning (if CONFIG_DEBUG_VM is specified).
I note that vma_merge() performs these invariant checks only after merge_prev/merge_next are checked, which is debatable as it hides this issue if no merge is possible even though a buggy situation has arisen.
The solution is simply to update the prev pointer even when policies are equal.
This caused a bug to arise in the 6.2.y stable tree, and this patch resolves this bug.
Link: https://lkml.kernel.org/r/83f1d612acb519d777bebf7f3359317c4e7f4265.168286662... Fixes: f4e9e0e69468 ("mm/mempolicy: fix use-after-free of VMA iterator") Signed-off-by: Lorenzo Stoakes lstoakes@gmail.com Reported-by: kernel test robot oliver.sang@intel.com Link: https://lore.kernel.org/oe-lkp/202304292203.44ddeff6-oliver.sang@intel.com Cc: Liam R. Howlett Liam.Howlett@oracle.com Cc: Mel Gorman mgorman@suse.de Cc: stable@vger.kernel.org Signed-off-by: Andrew Morton akpm@linux-foundation.org ---
mm/mempolicy.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/mm/mempolicy.c~mm-mempolicy-correctly-update-prev-when-policy-is-equal-on-mbind +++ a/mm/mempolicy.c @@ -808,8 +808,10 @@ static int mbind_range(struct vma_iterat vmstart = vma->vm_start; }
- if (mpol_equal(vma_policy(vma), new_pol)) + if (mpol_equal(vma_policy(vma), new_pol)) { + *prev = vma; return 0; + }
pgoff = vma->vm_pgoff + ((vmstart - vma->vm_start) >> PAGE_SHIFT); merged = vma_merge(vmi, vma->vm_mm, *prev, vmstart, vmend, vma->vm_flags, _
Patches currently in -mm which might be from lstoakes@gmail.com are
mm-mempolicy-correctly-update-prev-when-policy-is-equal-on-mbind.patch