github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-11-06 21:58:01 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph

mm/mremap: populate calculated fields in vrm state correctly

Browse Source 
Commit d5c8aec054 ("mm/mremap: initial refactor of move_vma()")
introduced the vma_remap_struct helper to pass state sanely through
mremap() logic.

Part of this state is vrm->delta - equal to the absolute difference between
vrm->old_len and vrm->new_len (the old and new lengths of the VMA,
respectively).

This value is used to correctly charge accounted VMAs.

When shrinking a VMA, mremap_to() sets vrm->old_len equal to vrm->new_len
having performed the shrink of the VMA first, prior to any potential move
(e.g.  MREMAP_FIXED | MREMAP_MAYMOVE specified).

However it does not recalculate vrm->delta, which results in incorrectly
overcharging the VMA when both moving and shrinking a VMA.

The charge leaks to Committed_AS globally, meaning a mischievous user can
cause allocations to fail across the system in strict overcommit mode.

Resolve the issue by abstracting the update of vrm->delta to
vrm_populate_calculated() and invoking this from mremap_to() when
vrm->old_len is changed.

Additionally, update vrm->remap_type whose value depends on vrm->delta. 
The field is not read again after the shrink, but it is the logically
correct thing to do and protects against future changes which break this.

Link: https://lore.kernel.org/20261019-mremap-fix-shrink-charge-v1-1-a3ce209e5360@kernel.org
Fixes: d5c8aec054 ("mm/mremap: initial refactor of move_vma()")
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Closes: https://lore.kernel.org/all/20261017233527.797191-1-nickolai@csail.mit.edu/
Reviewed-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Jann Horn <jannh@google.com>
Cc: <stable@vger.kernel.org>
This commit is contained in:
Lorenzo Stoakes (ARM) 2026-10-19 15:28:27 +01:00 committed by Andrew Morton
parent 1caede5a55
commit 34e753f8d9
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
mm/mremap.c
View File

@ -887,12 +887,6 @@ unsigned long move_page_tables(struct pagetable_move_control *pmc)
return pmc_progress(pmc);
}
/* Set vrm->delta to the difference in VMA size specified by user. */
static void vrm_set_delta(struct vma_remap_struct *vrm)
{
vrm->delta = abs_diff(vrm->old_len, vrm->new_len);
}
/* Determine what kind of remap this is - shrink, expand or no resize at all. */
static enum mremap_type vrm_remap_type(struct vma_remap_struct *vrm)
{
@ -905,6 +899,13 @@ static enum mremap_type vrm_remap_type(struct vma_remap_struct *vrm)
return MREMAP_EXPAND;
}
/* Populate calculated fields. */
static void vrm_populate_calculated(struct vma_remap_struct *vrm)
{
vrm->delta = abs_diff(vrm->old_len, vrm->new_len);
vrm->remap_type = vrm_remap_type(vrm);
}
/*
* When moving a VMA to vrm->new_adr, does this result in the new and old VMAs
* overlapping?
@ -1523,6 +1524,7 @@ static unsigned long mremap_to(struct vma_remap_struct *vrm)
/* Set up for the move now shrink has been executed. */
vrm->old_len = vrm->new_len;
vrm_populate_calculated(vrm);
}
/* MREMAP_DONTUNMAP expands by old_len since old_len == new_len */
@ -1795,8 +1797,7 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
if (vma_is_hugetlb(vma) && !align_hugetlb(vrm))
return -EINVAL;
vrm_set_delta(vrm);
vrm->remap_type = vrm_remap_type(vrm);
vrm_populate_calculated(vrm);
/* For convenience, we set new_addr even if VMA won't move. */
if (!vrm_implies_new_addr(vrm))
vrm->new_addr = addr;