linux-hardening - Re: [PATCH v1 1/2] mseal: fix mmap(FIXED) error code.

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: <vyllxuh5xbqmaoyl2mselebij5ox7cseekjcvl5gmzoxxwd2he@hxi4mpjanxzt>
Date: Thu, 29 Aug 2024 10:03:27 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Pedro Falcato <pedro.falcato@...il.com>
Cc: jeffxu@...omium.org, akpm@...ux-foundation.org,
        linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
        linux-hardening@...r.kernel.org, rientjes@...gle.com,
        keescook@...omium.org, vbabka@...e.cz, lorenzo.stoakes@...cle.com
Subject: Re: [PATCH v1 1/2] mseal: fix mmap(FIXED) error code.

* Pedro Falcato <pedro.falcato@...il.com> [240828 19:38]:
> +CC vma reviewers
> On Wed, Aug 28, 2024 at 10:55:21PM GMT, jeffxu@...omium.org wrote:
> > From: Jeff Xu <jeffxu@...omium.org>
> > 
> > mmap(MAP_FIXED) should return EPERM when memory is sealed.

Thanks for the fix and finding the issue.  Please email the maintainers
of the file as well as the patch author next time.

> > 
> > Fixes: 4205a39e06da ("mm/munmap: replace can_modify_mm with can_modify_vma")
> 
> Thank you for the patch!
> This Fixes: is wrong, the bug was added during Liam's rebasing of his munmap patch
> set on mine.

Right now, the akpm/mm-unstable git id of the patch this needs to squash
into is 5887a7ac23836.  Although, this will leave intermittent patches
to return the incorrect error code.

Initially it was introduced in commit c2eb22189bbc9, so I'd like to fix
this in the series so that it doesn't show up in any bisection.

> 
> > Signed-off-by: Jeff Xu <jeffxu@...omium.org>
> > ---
> >  mm/mmap.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 80d70ed099cf..0cd0c0ef03c7 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -1386,7 +1386,10 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> >  		mt_on_stack(mt_detach);
> >  		mas_init(&mas_detach, &mt_detach, /* addr = */ 0);
> >  		/* Prepare to unmap any existing mapping in the area */
> > -		if (vms_gather_munmap_vmas(&vms, &mas_detach))
> > +		error = vms_gather_munmap_vmas(&vms, &mas_detach);
> > +		if (error == -EPERM)
> > +			return -EPERM;
> 
> Not sure if it makes sense to special case this. We should probably deal with this inside
> vms_gather_munmap_vmas and just pass through the error we get.
> 
> Otherwise LGTM. Liam?
> 
> (we should also squash this into the offending commit)

All code paths that exist today in vms_gather_munmap_vmas() can only
return -EPERM and -ENOMEM. So filtering isn't really necessary right
now.  But then again, vms_gather_munmap_vmas() is only used in two
places and this filters one return, but not the other.

I think it best to address this in vms_gather_munmap_vmas() to only
return -ENOMEM or -EPERM.

I will fix this in my series, thanks Jeff.

Regards,
Liam