linux-kernel - Re: [PATCH] overflow check calculation in mm/mmap.c is incorrect linux-3.12.38

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87wq0j2yhe.fsf@rasmusvillemoes.dk>
Date:	Fri, 08 May 2015 11:46:21 +0200
From:	Rasmus Villemoes <linux@...musvillemoes.dk>
To:	"Reese Faucette" <reesefaucette@...il.com>
Cc:	<linux-kernel@...r.kernel.org>, <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] overflow check calculation in mm/mmap.c is incorrect linux-3.12.38

On Thu, Apr 30 2015, "Reese Faucette" <reesefaucette@...il.com> wrote:

> When checking for overflow, the code in mm/mmap.c compares the first byte
> *after* the end of mapped region to the start of the region instead of the
> last byte of the mapped region.  This prevents mapping a region which abuts
> the end of physical space, as mmap() incorrectly rejects the region with
> -EOVERFLOW, because pgoff + (len >> PAGE_SHIFT) will be 0, which is <
> pgoff.

Note this comment elsewhere in mmap.c:

 * We don't check here for the merged mmap wrapping around the end of pagecache
 * indices (16TB on ia32) because do_mmap_pgoff() does not permit mmap's which
 * wrap, nor mmaps which cover the final page at index -1UL.

So it seems to be by design.

But I'm also a little confused, since pgoff should be in units of pages (so a
20 bit number on 32bit), and I can't see how adding another 20 bit
number could ever make that overflow. Unless of course some magic power
ensures that pgoffs in the high half get sign-extended.

Rasmus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/