This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/21270] New: mmap64 silently truncates large offset values


https://sourceware.org/bugzilla/show_bug.cgi?id=21270

            Bug ID: 21270
           Summary: mmap64 silently truncates large offset values
           Product: glibc
           Version: 2.26
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: thiago at kde dot org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

sysdeps/unix/sysv/linux/mmap64.c:

    INLINE_SYSCALL (mmap2, 6, addr,
                    len, prot, flags, fd,
                    (off_t) (offset >> page_shift));

If one calls mmap64 with an offset value larger than 1 << (page_shift +
8*sizeof(off_t)) [that is, 1<<44], the system call silently truncates the
offset. This aliasing with lower offsets could result in file corruption, as
same area of the file could be mapped twice, unbeknownst to the application.

Other implementations:
 * the BSDs don't have mmap64: 32-bit mmap() takes 64-bit offsets
 * OpenSolaris has mmap64 and that maps 1:1 with the 64-bit system call
 * Bionic, uClibc, MUSL: all affected by the same issue

POSIX makes no provision for failing at mmap() if the offset is too large for
arbitary file descriptors. It says that the application should SIGBUS if access
is attempted. It does allow for EOVERFLOW for regular files:

[EOVERFLOW]
    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.

Other possible errors:
[ENXIO]
    Addresses in the range [off,off+len) are invalid for the object specified
by fildes.

Or ENOTSUPP.

If needed to keep a success result, then mmap64 could emulate the behaviour by
mapping one page past the end of a different (empty) file, opened in read-only
mode. This generates SIGBUS for reads and should be correct also for memory
writes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]