[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZGOworXBstm+jmw3@x1n>
Date: Tue, 16 May 2023 12:34:42 -0400
From: Peter Xu <peterx@...hat.com>
To: Jeff Xu <jeffxu@...omium.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, linux-hardening@...r.kernel.org,
Jorge Lucangeli Obes <jorgelo@...omium.org>,
lstoakes@...il.com, Liam.Howlett@...cle.com,
zhangpeng.00@...edance.com
Subject: Re: mprotect outbound check.
On Mon, May 15, 2023 at 06:41:35PM -0700, Jeff Xu wrote:
> + Peter, Lian, Lorenzo
>
> Is this related to this hotfix ?
> mm/mprotect: fix do_mprotect_pkey() return on error
Doesn't look like to me, that seems to only avoid replacing an error with
another error, rather than stop returning error for any case.
AFAIU this shouldn't be intentional, but Liam could correct. Maybe a
bisection would show at least when it got changed?
>
>
> Thanks!
>
> -Jeff
>
>
>
>
>
>
> On Mon, May 15, 2023 at 11:00 AM Jeff Xu <jeffxu@...omium.org> wrote:
> >
> > Noticed there is a slight change for mprotect between 6.1 and 6.4 RC1
> >
> > For example:
> > Consider the case below:
> > 1 mmap(0x5000000, PAGE_SIZE, ...)
> > 2 mprotect(0x5000000, PAGE_SIZE*4, ...)
> >
> > in 6.1 and before, 2 will fail, and in 6.4 RC1, it will pass.
> >
> > I know that munmap will accept out-of-bound cases like this (because
> > memory is freed anyway).
> >
> > Is this change intentional ?
> >
> > Thanks!
> > Best regards,
> > -Jeff
>
--
Peter Xu
Powered by blists - more mailing lists