Re: [PATCH] mm: fix mmap overflow checking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 05 Sep 2012 11:20:07 +0800
Wanlong Gao <gaowanlong@xxxxxxxxxxxxxx> wrote:

> On 09/05/2012 04:59 AM, Andrew Morton wrote:
> > On Tue, 4 Sep 2012 17:23:00 +0800
> > Wanlong Gao <gaowanlong@xxxxxxxxxxxxxx> 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
> 
> Current Linux checks whether the shifted off+len exceed ULONG_MAX, it seems
> never happen.
> 
> > 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?
> 
> What I saw is ENOMEM because the "len" here is too large.

I don't think I understand this.  You're saying that without your patch
applied, the mmap() attempt returns -ENOMEM?  If so, where in the code
does that occur?

In the current upstream kernel is there some combination of mmap()
arguments which will permit the mmap() to succeed, even though it
refers to a section of the file which lies beyond the file's maximum
offset?

> > 
> >> 	/* 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?
> 
> More reasonable, how about following?

Well I don't know.  Again, the concern here is the risk of breaking
existing applications.  So before proceeding, we need a very complete
and accurate understanding of the kernel's behaviour both before and
after this patch.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]