NetBSD Problem Report #49692

From www@NetBSD.org  Tue Feb 24 13:51:49 2015
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7A56CA567D
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 24 Feb 2015 13:51:49 +0000 (UTC)
Message-Id: <20150224135148.50DABA6552@mollari.NetBSD.org>
Date: Tue, 24 Feb 2015 13:51:48 +0000 (UTC)
From: justin@specialbusservice.com
Reply-To: justin@specialbusservice.com
To: gnats-bugs@NetBSD.org
Subject: impossibly large mmap does not fail
X-Send-Pr-Version: www-1.0

>Number:         49692
>Category:       kern
>Synopsis:       impossibly large mmap does not fail
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 24 13:55:00 +0000 2015
>Last-Modified:  Sun Mar 01 13:45:01 +0000 2015
>Originator:     Justin Cormack
>Release:        6.1.5 also 7.0 beta
>Organization:
>Environment:
NetBSD netbsd64-615.myriabit.eu 6.1.5 NetBSD 6.1.5 (XEN3_DOMU) amd64
NetBSD rhombus.myriabit.eu 7.0_BETA NetBSD 7.0_BETA (GENERIC.201409131930Z) amd64
>Description:
Calling mmap with an extremely long length does not fail, but returns a real address:


>How-To-Repeat:
#include <sys/mman.h>

int main()
{

        void *mem = mmap(0, (size_t)-1, PROT_READ | PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1, 0);

        return (mem == MAP_FAILED);
}

kdump:
 17781      1 ktrace   EMUL  "netbsd"
 17781      1 ktrace   RET   ktrace 0
 17781      1 ktrace   CALL  execve(0x7f7ffffffdff,0x7f7fffffdc48,0x7f7fffffdc58)
 17781      1 ktrace   NAMI  "/tmp/mm"
 17781      1 mm       EMUL  "netbsd"
 17781      1 mm       RET   execve JUSTRETURN
 17781      1 mm       CALL  __sysctl(0x41f8a0,2,0x62aae0,0x7f7fffffdbf8,0,0)
 17781      1 mm       RET   __sysctl 0
 17781      1 mm       CALL  mmap(0,0x18,3,0x1000,0xffffffff,0,0)
 17781      1 mm       RET   mmap 140187598319616/0x7f7ff7fff000
 17781      1 mm       CALL  _lwp_setprivate(0x7f7ff7fff000)
 17781      1 mm       RET   _lwp_setprivate 0
 17781      1 mm       CALL  mmap(0,0xffffffffffffffff,3,0x1002,0xffffffff,0,0)
 17781      1 mm       RET   mmap 140187598323712/0x7f7ff8000000
 17781      1 mm       CALL  exit(0)

This should fail with ENOMEM but it returned a valid address. 
>Fix:
Havent looked but guessing it is an overflow.

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/49692: impossibly large mmap does not fail
Date: Tue, 24 Feb 2015 19:53:29 +0100

 Note that -1 is not a multiple of the machines PAGE_SIZE, so it gets
 rounded up to the next full page.

 Martin

From: Justin Cormack <justin@specialbusservice.com>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org
Subject: Re: kern/49692: impossibly large mmap does not fail
Date: Tue, 24 Feb 2015 19:01:46 +0000

 On 24 February 2015 at 18:53, Martin Husemann <martin@duskware.de> wrote:
 > Note that -1 is not a multiple of the machines PAGE_SIZE, so it gets
 > rounded up to the next full page.

 Ah yes, -8192 say is ok and gives ENOMEM. But it is size_t so it is
 unsigned, so with *size_t)-1 that is an unsigned overflow to 0 that is
 taking place, which is undefined behaviour.

 Justin

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/49692: impossibly large mmap does not fail
Date: Sun, 1 Mar 2015 06:35:08 +0000

 On Tue, Feb 24, 2015 at 07:05:00PM +0000, Justin Cormack wrote:
  >  On 24 February 2015 at 18:53, Martin Husemann <martin@duskware.de> wrote:
  >  > Note that -1 is not a multiple of the machines PAGE_SIZE, so it gets
  >  > rounded up to the next full page.
  >  
  >  Ah yes, -8192 say is ok and gives ENOMEM. But it is size_t so it is
  >  unsigned, so with *size_t)-1 that is an unsigned overflow to 0 that is
  >  taking place, which is undefined behaviour.

 Eh wut? No it isn't. It's signed overflow that's undefined.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Justin Cormack <justin@specialbusservice.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/49692: impossibly large mmap does not fail
Date: Sun, 1 Mar 2015 10:03:22 +0000

 On 1 March 2015 at 06:40, David Holland <dholland-bugs@netbsd.org> wrote:
 > The following reply was made to PR kern/49692; it has been noted by GNATS.
 >
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: kern/49692: impossibly large mmap does not fail
 > Date: Sun, 1 Mar 2015 06:35:08 +0000
 >
 >  On Tue, Feb 24, 2015 at 07:05:00PM +0000, Justin Cormack wrote:
 >   >  On 24 February 2015 at 18:53, Martin Husemann <martin@duskware.de> wrote:
 >   >  > Note that -1 is not a multiple of the machines PAGE_SIZE, so it gets
 >   >  > rounded up to the next full page.
 >   >
 >   >  Ah yes, -8192 say is ok and gives ENOMEM. But it is size_t so it is
 >   >  unsigned, so with *size_t)-1 that is an unsigned overflow to 0 that is
 >   >  taking place, which is undefined behaviour.
 >
 >  Eh wut? No it isn't. It's signed overflow that's undefined.

 Indeed. So it seems harmless, if unexpected, so I guess we can close it.

 Justin

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/49692: impossibly large mmap does not fail
Date: Sun, 1 Mar 2015 14:01:34 +0100

 On Sun, Mar 01, 2015 at 06:40:01AM +0000, David Holland wrote:
 > The following reply was made to PR kern/49692; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/49692: impossibly large mmap does not fail
 > Date: Sun, 1 Mar 2015 06:35:08 +0000
 > 
 >  On Tue, Feb 24, 2015 at 07:05:00PM +0000, Justin Cormack wrote:
 >   >  On 24 February 2015 at 18:53, Martin Husemann <martin@duskware.de> wrote:
 >   >  > Note that -1 is not a multiple of the machines PAGE_SIZE, so it gets
 >   >  > rounded up to the next full page.
 >   >  
 >   >  Ah yes, -8192 say is ok and gives ENOMEM. But it is size_t so it is
 >   >  unsigned, so with *size_t)-1 that is an unsigned overflow to 0 that is
 >   >  taking place, which is undefined behaviour.
 >  
 >  Eh wut? No it isn't. It's signed overflow that's undefined.

 I still believe that we should catch it in the system call.

 Joerg

From: "Michael van Elst" <mlelstv@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/49692 CVS commit: src/sys/uvm
Date: Sun, 1 Mar 2015 13:43:51 +0000

 Module Name:	src
 Committed By:	mlelstv
 Date:		Sun Mar  1 13:43:51 UTC 2015

 Modified Files:
 	src/sys/uvm: uvm_mmap.c

 Log Message:
 Detect overflow when rounding length parameter and return ENOMEM.
 Fixes PR kern/49692.


 To generate a diff of this commit:
 cvs rdiff -u -r1.151 -r1.152 src/sys/uvm/uvm_mmap.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/49692: impossibly large mmap does not fail
Date: Sun, 1 Mar 2015 13:44:03 +0000 (UTC)

 joerg@britannica.bec.de (Joerg Sonnenberger) writes:

 > I still believe that we should catch it in the system call.

 We do now.


 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

Home	PR Database Search