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] [day] [month] [year] [list]

Message-ID: <80c43a45-afe9-4ec8-831f-fee68fe68fa2@lucifer.local>
Date: Sun, 20 Jul 2025 19:52:58 +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

On Sun, Jul 20, 2025 at 11:29:14AM -0700, Andrew Morton wrote:
> 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.

Thanks, all looks good to me!