From owner-freebsd-bugs@FreeBSD.ORG Mon Sep 20 14:29:45 2010 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 70525106566C; Mon, 20 Sep 2010 14:29:45 +0000 (UTC) Date: Mon, 20 Sep 2010 14:29:45 +0000 From: Alexander Best To: Alan Cox Message-ID: <20100920142945.GB28783@freebsd.org> References: <201009051525.o85FPFLa055194@freefall.freebsd.org> <4C96631E.40400@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C96631E.40400@rice.edu> Cc: alc@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/150260: mmap(2) fails with EPERM (not documented) if read-only shared memory is mmapped with MAP_PRIVATE & PROT_WRITE X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 14:29:45 -0000 On Sun Sep 19 10, Alan Cox wrote: > arundel@FreeBSD.org wrote: > >Synopsis: mmap(2) fails with EPERM (not documented) if read-only shared > >memory is mmapped with MAP_PRIVATE & PROT_WRITE > > > >Responsible-Changed-From-To: freebsd-bugs->alc > >Responsible-Changed-By: arundel > >Responsible-Changed-When: Sun Sep 5 15:21:21 UTC 2010 > >Responsible-Changed-Why: > >Alan might have an opinion on this PR. > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=150260 > > > > > > It's a legitimate bug. > > The attached program has a couple minor issues. It crashes on amd64 > because string.h is not included. (strerror() needs to be declared, > otherwise its return value is believed to be a 32-bit int, and not a > pointer.) Also, contrary to the bug description, the attached program > specifies MAP_SHARED where it clearly means to use MAP_PRIVATE. thanks a lot for taking care of this one and for committing the changes so quickly. :) i'll mark the PR 'patched' and will close it after r212873 gets MFC'ed to stable/8, since you pointed out that MFC'ing to stable/7 isn't necessary. this case might be worth including in a regression test. i'm not sure, but i think the currently available mmap() regression tests in src/tools/regression deal only with 'security.bsd.map_at_zero' related matters. this one by Jung-uk Kim seems very nice [1]. maybe i could ask him if he could add some more cases (including this one) and add it to the src tree. i'll take the source of the program that triggered this issue and hack in the changes (string.h and MAP_SHARED->MAP_PRIVATE) for any issues in the future. thanks again. :) cheers. alex [1] http://people.freebsd.org/~jkim/mmap_test.c > > I believe that the following change addresses the bug: > > Index: vm/vm_mmap.c > =================================================================== > --- vm/vm_mmap.c (revision 212830) > +++ vm/vm_mmap.c (working copy) > @@ -1373,7 +1373,8 @@ vm_mmap_shm(struct thread *td, vm_size_t objsize, > { > int error; > > - if ((*maxprotp & VM_PROT_WRITE) == 0 && > + if ((*flagsp & MAP_SHARED) != 0 && > + (*maxprotp & VM_PROT_WRITE) == 0 && > (prot & PROT_WRITE) != 0) > return (EACCES); > #ifdef MAC > -- a13x