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: <20250720112914.6692e658f4c5b7f4349214be@linux-foundation.org>
Date: Sun, 20 Jul 2025 11:29:14 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
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

On Sun, 20 Jul 2025 12:04:42 +0100 Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:

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

OK, I applied this as a -fix.

Moved the two new hunks into check_prep_vma().

Made sure the "We are expanding and the VMA .." hunk landed properly in
check_prep_vma().

I've pushed out the result, please check current mm-unstable.