From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx160.postini.com [74.125.245.160]) by kanga.kvack.org (Postfix) with SMTP id A34206B0069 for ; Tue, 4 Sep 2012 16:59:25 -0400 (EDT) Date: Tue, 4 Sep 2012 13:59:24 -0700 From: Andrew Morton Subject: Re: [PATCH] mm: fix mmap overflow checking Message-Id: <20120904135924.b61e04e0.akpm@linux-foundation.org> In-Reply-To: <1346750580-11352-1-git-send-email-gaowanlong@cn.fujitsu.com> References: <1346750580-11352-1-git-send-email-gaowanlong@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Wanlong Gao Cc: linux-kernel@vger.kernel.org, KOSAKI Motohiro , "open list:MEMORY MANAGEMENT" On Tue, 4 Sep 2012 17:23:00 +0800 Wanlong Gao wrote: > POSIX said that if the file is a regular file and the value of "off" > plus "len" exceeds the offset maximum established in the open file > description associated with fildes, mmap should return EOVERFLOW. That's what POSIX says, but what does Linux do? It is important that we precisely describe and understand the behaviour change, as there is potential here to break existing applications. I'm assuming that Linux presently permits the mmap() and then generates SIGBUS if an access is attempted beyond the max file size? > /* offset overflow? */ > - if ((pgoff + (len >> PAGE_SHIFT)) < pgoff) > - return -EOVERFLOW; > + if (off + len < off) > + return -EOVERFLOW; Well, this treats sizeof(off_t) as the "offset maximum established in the open file". But from my reading of the above excerpt, we should in fact be checking against the underlying fs's s_maxbytes? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757832Ab2IDU71 (ORCPT ); Tue, 4 Sep 2012 16:59:27 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:53823 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757793Ab2IDU7Z (ORCPT ); Tue, 4 Sep 2012 16:59:25 -0400 Date: Tue, 4 Sep 2012 13:59:24 -0700 From: Andrew Morton To: Wanlong Gao Cc: linux-kernel@vger.kernel.org, KOSAKI Motohiro , linux-mm@kvack.org (open list:MEMORY MANAGEMENT) Subject: Re: [PATCH] mm: fix mmap overflow checking Message-Id: <20120904135924.b61e04e0.akpm@linux-foundation.org> In-Reply-To: <1346750580-11352-1-git-send-email-gaowanlong@cn.fujitsu.com> References: <1346750580-11352-1-git-send-email-gaowanlong@cn.fujitsu.com> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 4 Sep 2012 17:23:00 +0800 Wanlong Gao wrote: > POSIX said that if the file is a regular file and the value of "off" > plus "len" exceeds the offset maximum established in the open file > description associated with fildes, mmap should return EOVERFLOW. That's what POSIX says, but what does Linux do? It is important that we precisely describe and understand the behaviour change, as there is potential here to break existing applications. I'm assuming that Linux presently permits the mmap() and then generates SIGBUS if an access is attempted beyond the max file size? > /* offset overflow? */ > - if ((pgoff + (len >> PAGE_SHIFT)) < pgoff) > - return -EOVERFLOW; > + if (off + len < off) > + return -EOVERFLOW; Well, this treats sizeof(off_t) as the "offset maximum established in the open file". But from my reading of the above excerpt, we should in fact be checking against the underlying fs's s_maxbytes?