Re: svn commit: r348843 - head/sys/vm

2019-06-12 Thread Brooks Davis
On Mon, Jun 10, 2019 at 09:00:34AM -0400, Shawn Webb wrote:
> On Mon, Jun 10, 2019 at 03:07:11AM +, Doug Moore wrote:
> > Author: dougm
> > Date: Mon Jun 10 03:07:10 2019
> > New Revision: 348843
> > URL: https://svnweb.freebsd.org/changeset/base/348843
> > 
> > Log:
> >   There are times when a len==0 parameter to mmap is okay. But on a
> >   32-bit machine, a len parameter just a few bytes short of 4G, rounded
> >   up to a page boundary and hitting zero then, is not okay. Return
> >   failure in that case.
> >   
> >   Reported by: pho
> >   Reviewed by: alc, kib (mentor)
> >   Tested by: pho
> >   Differential Revision: https://reviews.freebsd.org/D20580
> > 
> > Modified:
> >   head/sys/vm/vm_mmap.c
> > 
> > Modified: head/sys/vm/vm_mmap.c
> > ==
> > --- head/sys/vm/vm_mmap.c   Sun Jun  9 22:55:21 2019(r348842)
> > +++ head/sys/vm/vm_mmap.c   Mon Jun 10 03:07:10 2019(r348843)
> > @@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s
> >  
> > /* Adjust size for rounding (on both ends). */
> > size += pageoff;/* low end... */
> > -   size = (vm_size_t) round_page(size);/* hi end */
> > +   /* Check for rounding up to zero. */
> > +   if (round_page(size) < size)
> > +   return (EINVAL);
> 
> The mmap(2) manpage says that len==0 results in EINVAL, so the manpage
> needs updating.

The manpage is correct for ABIs people are actually writing code for
(ELF).  I suppose it could document the exception for a.out (see the
conditional containing SV_CURPROC_FLAG(SV_AOUT) in kern_mmap()), but it
should be in BUGS, HISTORY, or some such.

-- Brooks


signature.asc
Description: PGP signature


Re: svn commit: r348843 - head/sys/vm

2019-06-10 Thread Shawn Webb
On Tue, Jun 11, 2019 at 01:33:23AM +1000, Bruce Evans wrote:
> On Mon, 10 Jun 2019, Shawn Webb wrote:
> 
> > On Mon, Jun 10, 2019 at 03:07:11AM +, Doug Moore wrote:
> > > ...
> > > Log:
> > >   There are times when a len==0 parameter to mmap is okay. But on a
> > >   32-bit machine, a len parameter just a few bytes short of 4G, rounded
> > >   up to a page boundary and hitting zero then, is not okay. Return
> > >   failure in that case.
> > > ...
> > >   /* Adjust size for rounding (on both ends). */
> > >   size += pageoff;/* low end... */
> > > - size = (vm_size_t) round_page(size);/* hi end */
> > > + /* Check for rounding up to zero. */
> > > + if (round_page(size) < size)
> > > + return (EINVAL);
> > 
> > The mmap(2) manpage says that len==0 results in EINVAL, so the manpage
> > needs updating.
> 
> The man page doesn't say that only len == 0 results in EINVAL, so it is
> not incorrect.

https://github.com/freebsd/freebsd/blob/master/lib/libc/sys/mmap.2#L451-L455

Tons of error conditions listed, one of which is len==0.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2


signature.asc
Description: PGP signature


Re: svn commit: r348843 - head/sys/vm

2019-06-10 Thread Bruce Evans

On Mon, 10 Jun 2019, Shawn Webb wrote:


On Mon, Jun 10, 2019 at 03:07:11AM +, Doug Moore wrote:

...
Log:
  There are times when a len==0 parameter to mmap is okay. But on a
  32-bit machine, a len parameter just a few bytes short of 4G, rounded
  up to a page boundary and hitting zero then, is not okay. Return
  failure in that case.
...
/* Adjust size for rounding (on both ends). */
size += pageoff;/* low end... */
-   size = (vm_size_t) round_page(size);/* hi end */
+   /* Check for rounding up to zero. */
+   if (round_page(size) < size)
+   return (EINVAL);


The mmap(2) manpage says that len==0 results in EINVAL, so the manpage
needs updating.


The man page doesn't say that only len == 0 results in EINVAL, so it is
not incorrect.

However, the errno here is incorrect.  POSIX specifies that the errno is
ENOMEM if MAP_FIXED was specified, and the range [addr,addr+len) exceeds
that allowed for the address space of the process; or, if MAP_FIXED was
not specified and there is insufficient room in the address space to effect
the mapping.  There are 2 other meanings for ENOMEM in POSIX.1-2001.

The man page documents ENOMEM, but only has a small fraction of the above
case, and no other cases.  It says that the errno is ENOMEM if MAP_FIXED was
specified and the addr argument was not available, or MAP_ANON was specified
and insufficient memory was available.  Who knows what it means for the addr
argument to be no available?

The other cases specified by POSIX but not the man page are: (1) under the
ML extension, if the mapping could not be locked...  (1a) MAP_FIXED or
MAP_PRIVATE was specified and the implementation does not support this
(but FreeBSD does support this, at least for most file types).  (2) under
the TYM extension, not enough resources in the typed memory object
designated by filedes...


I'm curious what "there are times" refers to. Can you or the original
reporter elaborate those cases?


When len == 0 is actually a parameter, and with other parameters specifying
that len == 0 is meaningful.

The code has various style bugs starting with renaming the len parameter to
a size parameter for a layered function.  So it is not actually the len
parameter that is adjusted, but adjusting it is still a style bug since it
reuses a function parameter so the original parameter is harder to describe
and to debug.

Bruce
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r348843 - head/sys/vm

2019-06-10 Thread Doug Moore
The comment and the code that rejects size==0, or doesn't, are copied
below.  Konstantin Belousov is the last person to have touched most of
it, and can better explain its meaning than I.

Doug Moore

    /*
     * Enforce the constraints.
     * Mapping of length 0 is only allowed for old binaries.
     * Anonymous mapping shall specify -1 as filedescriptor and
     * zero position for new code. Be nice to ancient a.out
     * binaries and correct pos for anonymous mapping, since old
     * ld.so sometimes issues anonymous map requests with non-zero
     * pos.
     */
    if (!SV_CURPROC_FLAG(SV_AOUT)) {
        if ((size == 0 && curproc->p_osrel >= P_OSREL_MAP_ANON) ||
            ((flags & MAP_ANON) != 0 && (fd != -1 || pos != 0)))
            return (EINVAL);
    } else {
        if ((flags & MAP_ANON) != 0)
            pos = 0;
    }

On 6/10/19 9:27 AM, Shawn Webb wrote:
> Sounds good! I think the manpage still might still need a change
> to match the current behavior, or perhaps matching something similar
> to that vm_mmap.c comment. But that comment brings another question:
> what's the definition of "old binaries"? a.out?
>
> Thanks,
>

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r348843 - head/sys/vm

2019-06-10 Thread Shawn Webb
Sounds good! I think the manpage still might still need a change
to match the current behavior, or perhaps matching something similar
to that vm_mmap.c comment. But that comment brings another question:
what's the definition of "old binaries"? a.out?

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2

On Mon, Jun 10, 2019 at 09:19:55AM -0500, Doug Moore wrote:
> This comment appears in vm_mmap.c:
> 
>  * Mapping of length 0 is only allowed for old binaries.
> 
> and my intent was to say, to whoever wrote that comment, that I was not
> disallowing the mapping of length zero with this change.? I was only
> intending to affect a case in which the length was transformed to zero,
> and which was the problem that Peter Holm reported.
> 
> Doug Moore
> 
> On 6/10/19 8:00 AM, Shawn Webb wrote:
> > On Mon, Jun 10, 2019 at 03:07:11AM +, Doug Moore wrote:
> >> Author: dougm
> >> Date: Mon Jun 10 03:07:10 2019
> >> New Revision: 348843
> >> URL: https://svnweb.freebsd.org/changeset/base/348843
> >>
> >> Log:
> >>   There are times when a len==0 parameter to mmap is okay. But on a
> >>   32-bit machine, a len parameter just a few bytes short of 4G, rounded
> >>   up to a page boundary and hitting zero then, is not okay. Return
> >>   failure in that case.
> >>   
> >>   Reported by: pho
> >>   Reviewed by: alc, kib (mentor)
> >>   Tested by: pho
> >>   Differential Revision: https://reviews.freebsd.org/D20580
> >>
> >> Modified:
> >>   head/sys/vm/vm_mmap.c
> >>
> >> Modified: head/sys/vm/vm_mmap.c
> >> ==
> >> --- head/sys/vm/vm_mmap.c  Sun Jun  9 22:55:21 2019(r348842)
> >> +++ head/sys/vm/vm_mmap.c  Mon Jun 10 03:07:10 2019(r348843)
> >> @@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s
> >>  
> >>/* Adjust size for rounding (on both ends). */
> >>size += pageoff;/* low end... */
> >> -  size = (vm_size_t) round_page(size);/* hi end */
> >> +  /* Check for rounding up to zero. */
> >> +  if (round_page(size) < size)
> >> +  return (EINVAL);
> > The mmap(2) manpage says that len==0 results in EINVAL, so the manpage
> > needs updating.
> >
> > I'm curious what "there are times" refers to. Can you or the original
> > reporter elaborate those cases?
> >
> > Thanks a lot!
> >


signature.asc
Description: PGP signature


Re: svn commit: r348843 - head/sys/vm

2019-06-10 Thread Doug Moore
This comment appears in vm_mmap.c:

 * Mapping of length 0 is only allowed for old binaries.

and my intent was to say, to whoever wrote that comment, that I was not
disallowing the mapping of length zero with this change.  I was only
intending to affect a case in which the length was transformed to zero,
and which was the problem that Peter Holm reported.

Doug Moore

On 6/10/19 8:00 AM, Shawn Webb wrote:
> On Mon, Jun 10, 2019 at 03:07:11AM +, Doug Moore wrote:
>> Author: dougm
>> Date: Mon Jun 10 03:07:10 2019
>> New Revision: 348843
>> URL: https://svnweb.freebsd.org/changeset/base/348843
>>
>> Log:
>>   There are times when a len==0 parameter to mmap is okay. But on a
>>   32-bit machine, a len parameter just a few bytes short of 4G, rounded
>>   up to a page boundary and hitting zero then, is not okay. Return
>>   failure in that case.
>>   
>>   Reported by: pho
>>   Reviewed by: alc, kib (mentor)
>>   Tested by: pho
>>   Differential Revision: https://reviews.freebsd.org/D20580
>>
>> Modified:
>>   head/sys/vm/vm_mmap.c
>>
>> Modified: head/sys/vm/vm_mmap.c
>> ==
>> --- head/sys/vm/vm_mmap.cSun Jun  9 22:55:21 2019(r348842)
>> +++ head/sys/vm/vm_mmap.cMon Jun 10 03:07:10 2019(r348843)
>> @@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s
>>  
>>  /* Adjust size for rounding (on both ends). */
>>  size += pageoff;/* low end... */
>> -size = (vm_size_t) round_page(size);/* hi end */
>> +/* Check for rounding up to zero. */
>> +if (round_page(size) < size)
>> +return (EINVAL);
> The mmap(2) manpage says that len==0 results in EINVAL, so the manpage
> needs updating.
>
> I'm curious what "there are times" refers to. Can you or the original
> reporter elaborate those cases?
>
> Thanks a lot!
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r348843 - head/sys/vm

2019-06-10 Thread Shawn Webb
On Mon, Jun 10, 2019 at 03:07:11AM +, Doug Moore wrote:
> Author: dougm
> Date: Mon Jun 10 03:07:10 2019
> New Revision: 348843
> URL: https://svnweb.freebsd.org/changeset/base/348843
> 
> Log:
>   There are times when a len==0 parameter to mmap is okay. But on a
>   32-bit machine, a len parameter just a few bytes short of 4G, rounded
>   up to a page boundary and hitting zero then, is not okay. Return
>   failure in that case.
>   
>   Reported by: pho
>   Reviewed by: alc, kib (mentor)
>   Tested by: pho
>   Differential Revision: https://reviews.freebsd.org/D20580
> 
> Modified:
>   head/sys/vm/vm_mmap.c
> 
> Modified: head/sys/vm/vm_mmap.c
> ==
> --- head/sys/vm/vm_mmap.c Sun Jun  9 22:55:21 2019(r348842)
> +++ head/sys/vm/vm_mmap.c Mon Jun 10 03:07:10 2019(r348843)
> @@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s
>  
>   /* Adjust size for rounding (on both ends). */
>   size += pageoff;/* low end... */
> - size = (vm_size_t) round_page(size);/* hi end */
> + /* Check for rounding up to zero. */
> + if (round_page(size) < size)
> + return (EINVAL);

The mmap(2) manpage says that len==0 results in EINVAL, so the manpage
needs updating.

I'm curious what "there are times" refers to. Can you or the original
reporter elaborate those cases?

Thanks a lot!

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2


signature.asc
Description: PGP signature


Re: svn commit: r348843 - head/sys/vm

2019-06-10 Thread Andriy Gapon
On 10/06/2019 09:42, Doug Moore wrote:
> -fwrapv concerns signed arithmetic.  This calculation is with unsigned
> arithmetic, and the possibility of wrapping around to 0 is part of the
> language.

Oh, sorry for the noise!

> On 6/10/19 1:35 AM, Andriy Gapon wrote:
>> On 10/06/2019 06:07, Doug Moore wrote:
>>> Author: dougm
>>> Date: Mon Jun 10 03:07:10 2019
>>> New Revision: 348843
>>> URL: https://svnweb.freebsd.org/changeset/base/348843
>>>
>>> Log:
>>>   There are times when a len==0 parameter to mmap is okay. But on a
>>>   32-bit machine, a len parameter just a few bytes short of 4G, rounded
>>>   up to a page boundary and hitting zero then, is not okay. Return
>>>   failure in that case.
>>>   
>>>   Reported by: pho
>>>   Reviewed by: alc, kib (mentor)
>>>   Tested by: pho
>>>   Differential Revision: https://reviews.freebsd.org/D20580
>>>
>>> Modified:
>>>   head/sys/vm/vm_mmap.c
>>>
>>> Modified: head/sys/vm/vm_mmap.c
>>> ==
>>> --- head/sys/vm/vm_mmap.c   Sun Jun  9 22:55:21 2019(r348842)
>>> +++ head/sys/vm/vm_mmap.c   Mon Jun 10 03:07:10 2019(r348843)
>>> @@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s
>>>  
>>> /* Adjust size for rounding (on both ends). */
>>> size += pageoff;/* low end... */
>>> -   size = (vm_size_t) round_page(size);/* hi end */
>>> +   /* Check for rounding up to zero. */
>>> +   if (round_page(size) < size)
>> Is this guaranteed to work with all compilers?
>> I think that some smart compilers may think that this condition is 
>> impossible.
>> Are we finally using -fwrapv or something like it for kernel builds?
>>
>>> +   return (EINVAL);
>>> +   size = round_page(size);/* hi end */
>>>  
>>> /* Ensure alignment is at least a page and fits in a pointer. */
>>> align = flags & MAP_ALIGNMENT_MASK;
>>>
>>


-- 
Andriy Gapon
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r348843 - head/sys/vm

2019-06-10 Thread Bruce Evans

On Mon, 10 Jun 2019, Doug Moore wrote:


Log:
 There are times when a len==0 parameter to mmap is okay. But on a
 32-bit machine, a len parameter just a few bytes short of 4G, rounded
 up to a page boundary and hitting zero then, is not okay. Return
 failure in that case.


Some overflows still occur.

The problem is not limited to 32-bit machines.  The first overflow is for
len parameter just a few bytes short of SIZE_MAX added to a page offset of
a few bytes.  This overflows to a small value.  Then rounding up to a page
boundary doesn't overflow, but gives 0 or PAGE_SIZE, so the new overflow
check doesn't work and overflow still occurs.

The second overflow is for a len parameter just a few bytes short of
SIZE_MAX with the first overflow not occurring (usually because the offset
is 0).  This is now detected.


 Reported by: pho
 Reviewed by: alc, kib (mentor)
 Tested by: pho
 Differential Revision: https://reviews.freebsd.org/D20580

Modified:
 head/sys/vm/vm_mmap.c

Modified: head/sys/vm/vm_mmap.c
==
--- head/sys/vm/vm_mmap.c   Sun Jun  9 22:55:21 2019(r348842)
+++ head/sys/vm/vm_mmap.c   Mon Jun 10 03:07:10 2019(r348843)
@@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s

/* Adjust size for rounding (on both ends). */
size += pageoff;/* low end... */


The first overflow occurs here.  Except in special cases, pageoff can be
anything between 0 and PAGE_SIZE - 1, and size can be anything between 0
and SIZE_MAX.


-   size = (vm_size_t) round_page(size);/* hi end */
+   /* Check for rounding up to zero. */
+   if (round_page(size) < size)
+   return (EINVAL);
+   size = round_page(size);/* hi end */

/* Ensure alignment is at least a page and fits in a pointer. */
align = flags & MAP_ALIGNMENT_MASK;


This bug was implemented in r239247 and affects all versions of FreeBSD
newer than FreeBSD-7.  Before then, FreeBSD used the bogus 4.4BSD check
that (ssize_t)uap->len >= 0 (else return EINVAL).  This behaviour was
even documented.  POSIX doesn't allow this -- it requires ENOMEM for
invalid ranges, though it should require EOVERFLOW for ranges that are
so invalid that they overflow something.

Bruce
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r348843 - head/sys/vm

2019-06-10 Thread Doug Moore
-fwrapv concerns signed arithmetic.  This calculation is with unsigned
arithmetic, and the possibility of wrapping around to 0 is part of the
language.

Doug Moore

On 6/10/19 1:35 AM, Andriy Gapon wrote:
> On 10/06/2019 06:07, Doug Moore wrote:
>> Author: dougm
>> Date: Mon Jun 10 03:07:10 2019
>> New Revision: 348843
>> URL: https://svnweb.freebsd.org/changeset/base/348843
>>
>> Log:
>>   There are times when a len==0 parameter to mmap is okay. But on a
>>   32-bit machine, a len parameter just a few bytes short of 4G, rounded
>>   up to a page boundary and hitting zero then, is not okay. Return
>>   failure in that case.
>>   
>>   Reported by: pho
>>   Reviewed by: alc, kib (mentor)
>>   Tested by: pho
>>   Differential Revision: https://reviews.freebsd.org/D20580
>>
>> Modified:
>>   head/sys/vm/vm_mmap.c
>>
>> Modified: head/sys/vm/vm_mmap.c
>> ==
>> --- head/sys/vm/vm_mmap.cSun Jun  9 22:55:21 2019(r348842)
>> +++ head/sys/vm/vm_mmap.cMon Jun 10 03:07:10 2019(r348843)
>> @@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s
>>  
>>  /* Adjust size for rounding (on both ends). */
>>  size += pageoff;/* low end... */
>> -size = (vm_size_t) round_page(size);/* hi end */
>> +/* Check for rounding up to zero. */
>> +if (round_page(size) < size)
> Is this guaranteed to work with all compilers?
> I think that some smart compilers may think that this condition is impossible.
> Are we finally using -fwrapv or something like it for kernel builds?
>
>> +return (EINVAL);
>> +size = round_page(size);/* hi end */
>>  
>>  /* Ensure alignment is at least a page and fits in a pointer. */
>>  align = flags & MAP_ALIGNMENT_MASK;
>>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r348843 - head/sys/vm

2019-06-10 Thread Andriy Gapon
On 10/06/2019 06:07, Doug Moore wrote:
> Author: dougm
> Date: Mon Jun 10 03:07:10 2019
> New Revision: 348843
> URL: https://svnweb.freebsd.org/changeset/base/348843
> 
> Log:
>   There are times when a len==0 parameter to mmap is okay. But on a
>   32-bit machine, a len parameter just a few bytes short of 4G, rounded
>   up to a page boundary and hitting zero then, is not okay. Return
>   failure in that case.
>   
>   Reported by: pho
>   Reviewed by: alc, kib (mentor)
>   Tested by: pho
>   Differential Revision: https://reviews.freebsd.org/D20580
> 
> Modified:
>   head/sys/vm/vm_mmap.c
> 
> Modified: head/sys/vm/vm_mmap.c
> ==
> --- head/sys/vm/vm_mmap.c Sun Jun  9 22:55:21 2019(r348842)
> +++ head/sys/vm/vm_mmap.c Mon Jun 10 03:07:10 2019(r348843)
> @@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s
>  
>   /* Adjust size for rounding (on both ends). */
>   size += pageoff;/* low end... */
> - size = (vm_size_t) round_page(size);/* hi end */
> + /* Check for rounding up to zero. */
> + if (round_page(size) < size)

Is this guaranteed to work with all compilers?
I think that some smart compilers may think that this condition is impossible.
Are we finally using -fwrapv or something like it for kernel builds?

> + return (EINVAL);
> + size = round_page(size);/* hi end */
>  
>   /* Ensure alignment is at least a page and fits in a pointer. */
>   align = flags & MAP_ALIGNMENT_MASK;
> 


-- 
Andriy Gapon
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r348843 - head/sys/vm

2019-06-09 Thread Doug Moore
I understand that I ought to have included this in the previous checkin.

MFC after: 3 days

and that my description of the appropriateness of len==0 passed to mmap
was imprecise.  I regret the error.

Doug Moore

On 6/9/19 10:07 PM, Doug Moore wrote:
> Author: dougm
> Date: Mon Jun 10 03:07:10 2019
> New Revision: 348843
> URL: https://svnweb.freebsd.org/changeset/base/348843
>
> Log:
>   There are times when a len==0 parameter to mmap is okay. But on a
>   32-bit machine, a len parameter just a few bytes short of 4G, rounded
>   up to a page boundary and hitting zero then, is not okay. Return
>   failure in that case.
>   
>   Reported by: pho
>   Reviewed by: alc, kib (mentor)
>   Tested by: pho
>   Differential Revision: https://reviews.freebsd.org/D20580
>
> Modified:
>   head/sys/vm/vm_mmap.c
>
> Modified: head/sys/vm/vm_mmap.c
> ==
> --- head/sys/vm/vm_mmap.c Sun Jun  9 22:55:21 2019(r348842)
> +++ head/sys/vm/vm_mmap.c Mon Jun 10 03:07:10 2019(r348843)
> @@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s
>  
>   /* Adjust size for rounding (on both ends). */
>   size += pageoff;/* low end... */
> - size = (vm_size_t) round_page(size);/* hi end */
> + /* Check for rounding up to zero. */
> + if (round_page(size) < size)
> + return (EINVAL);
> + size = round_page(size);/* hi end */
>  
>   /* Ensure alignment is at least a page and fits in a pointer. */
>   align = flags & MAP_ALIGNMENT_MASK;
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r348843 - head/sys/vm

2019-06-09 Thread Doug Moore
Author: dougm
Date: Mon Jun 10 03:07:10 2019
New Revision: 348843
URL: https://svnweb.freebsd.org/changeset/base/348843

Log:
  There are times when a len==0 parameter to mmap is okay. But on a
  32-bit machine, a len parameter just a few bytes short of 4G, rounded
  up to a page boundary and hitting zero then, is not okay. Return
  failure in that case.
  
  Reported by: pho
  Reviewed by: alc, kib (mentor)
  Tested by: pho
  Differential Revision: https://reviews.freebsd.org/D20580

Modified:
  head/sys/vm/vm_mmap.c

Modified: head/sys/vm/vm_mmap.c
==
--- head/sys/vm/vm_mmap.c   Sun Jun  9 22:55:21 2019(r348842)
+++ head/sys/vm/vm_mmap.c   Mon Jun 10 03:07:10 2019(r348843)
@@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s
 
/* Adjust size for rounding (on both ends). */
size += pageoff;/* low end... */
-   size = (vm_size_t) round_page(size);/* hi end */
+   /* Check for rounding up to zero. */
+   if (round_page(size) < size)
+   return (EINVAL);
+   size = round_page(size);/* hi end */
 
/* Ensure alignment is at least a page and fits in a pointer. */
align = flags & MAP_ALIGNMENT_MASK;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"