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."
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.