linux-hardening.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* mprotect outbound check.
@ 2023-05-15 18:00 Jeff Xu
  2023-05-16  1:41 ` Jeff Xu
  0 siblings, 1 reply; 4+ messages in thread
From: Jeff Xu @ 2023-05-15 18:00 UTC (permalink / raw)
  To: linux-mm, linux-kernel, akpm, linux-hardening, Jorge Lucangeli Obes

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: mprotect outbound check.
  2023-05-15 18:00 mprotect outbound check Jeff Xu
@ 2023-05-16  1:41 ` Jeff Xu
  2023-05-16 16:34   ` Peter Xu
  0 siblings, 1 reply; 4+ messages in thread
From: Jeff Xu @ 2023-05-16  1:41 UTC (permalink / raw)
  To: linux-mm, linux-kernel, akpm, linux-hardening,
	Jorge Lucangeli Obes, lstoakes, Liam.Howlett, peterx,
	zhangpeng.00

+ Peter, Lian, Lorenzo

Is this related to this hotfix ?
      mm/mprotect: fix do_mprotect_pkey() return on error


Thanks!

-Jeff






On Mon, May 15, 2023 at 11:00 AM Jeff Xu <jeffxu@chromium.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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: mprotect outbound check.
  2023-05-16  1:41 ` Jeff Xu
@ 2023-05-16 16:34   ` Peter Xu
  2023-05-16 16:57     ` Liam R. Howlett
  0 siblings, 1 reply; 4+ messages in thread
From: Peter Xu @ 2023-05-16 16:34 UTC (permalink / raw)
  To: Jeff Xu
  Cc: linux-mm, linux-kernel, akpm, linux-hardening,
	Jorge Lucangeli Obes, lstoakes, Liam.Howlett, zhangpeng.00

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: mprotect outbound check.
  2023-05-16 16:34   ` Peter Xu
@ 2023-05-16 16:57     ` Liam R. Howlett
  0 siblings, 0 replies; 4+ messages in thread
From: Liam R. Howlett @ 2023-05-16 16:57 UTC (permalink / raw)
  To: Peter Xu
  Cc: Jeff Xu, linux-mm, linux-kernel, akpm, linux-hardening,
	Jorge Lucangeli Obes, lstoakes, zhangpeng.00

* Peter Xu <peterx@redhat.com> [230516 12:35]:
> 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?

I did not intentionally modify the return of mprotect for this case.  As
Peter said, that change shouldn't cause the change in behaviour you are
seeing.

A bisection would help narrow it down, as it could be changes to mm/mmap
vma_merge() and friends.

Thanks,
Liam

> 
> > 
> > 
> > Thanks!
> > 
> > -Jeff
> > 
> > 
> > 
> > 
> > 
> > 
> > On Mon, May 15, 2023 at 11:00 AM Jeff Xu <jeffxu@chromium.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
> 
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-05-16 16:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-15 18:00 mprotect outbound check Jeff Xu
2023-05-16  1:41 ` Jeff Xu
2023-05-16 16:34   ` Peter Xu
2023-05-16 16:57     ` Liam R. Howlett

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).