linux-kernel - Re: [PATCH v4 06/10] mm/mremap: check remap conditions earlier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8fc92a38-c636-465e-9a2f-2c6ac9cb49b8@lucifer.local>
Date: Sun, 20 Jul 2025 12:04:42 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Peter Xu <peterx@...hat.com>, Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
        Pedro Falcato <pfalcato@...e.de>, Rik van Riel <riel@...riel.com>,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH v4 06/10] mm/mremap: check remap conditions earlier

Hi Andrew,

It turns out there's some undocumented, unusual behaviour in mremap()
around shrinking of a range which was previously missed, but an LTP test
flagged up (seemingly by accident).

Basically, if you specify an input range that spans multiple VMAs, this is
in nearly all cases rejected (this is the point of this series, after all,
for VMA moves).

However, it turns out if you a. shrink a range and b. the new size spans
only a single VMA in the original range - then this requirement is entirely
dropped.

So I need to slightly adjust the logic to account for this. I will also be
documenting this in the man page as it appears the man page contradicts
this or is at least very unclear.

I attach a fix-patch, however there's some very trivial conflicts caused
due to code being moved around.

If you'd therefore prefer me to send a respin, I can do so.

This doesn't reflect on the series itself, which with the corner-case VMA
iterator stuff sorted is fine, but is rather just an undocumented and
unusual behaviour that it seems very few were aware of.

With all other tests passing this series should be fine with this fix
applied. I've run all self-tests and the LTP tests against this.

Cheers, Lorenzo

[0]: https://lore.kernel.org/all/202507201002.69144b74-lkp@intel.com/

----8<----
>From 23b95070152b22f7432c4a9da9e4b5718f9d115f Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Date: Sun, 20 Jul 2025 11:41:48 +0100
Subject: [PATCH] mm/mremap: allow undocumented mremap() shrink behaviour

It turns out that, in apparent contradiction to the man page, and at odds
with every other mremap() operation - we are allowed to specify an input
addr, old_len range that spans any number of VMAs and any number of gaps,
as long as we shrink that range to the point at which the new range spans
only one.

In order to accommodate this, adjust the remap validity check to account
for this.

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Reported-by: kernel test robot <oliver.sang@...el.com>
Closes: https://lore.kernel.org/oe-lkp/202507201002.69144b74-lkp@intel.com
---
 mm/mremap.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/mm/mremap.c b/mm/mremap.c
index 20844fb91755..11a8321a90b8 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -1339,11 +1339,18 @@ static int remap_is_valid(struct vma_remap_struct *vrm)
 			(vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)))
 		return -EINVAL;

+	/*
+	 * We permit crossing of boundaries for the range being unmapped due to
+	 * a shrink.
+	 */
+	if (vrm->remap_type == MREMAP_SHRINK)
+		old_len = new_len;
+
 	/* We can't remap across vm area boundaries */
 	if (old_len > vma->vm_end - addr)
 		return -EFAULT;

-	if (new_len <= old_len)
+	if (new_len == old_len)
 		return 0;

 	/* Need to be careful about a growing mapping */
--
2.50.1