SOLARIS: corrupted content of mmap'd files over 4GiB 92/12292/2
authorMark Vitale <mvitale@sinenomine.net>
Fri, 27 May 2016 20:44:17 +0000 (16:44 -0400)
committerBenjamin Kaduk <kaduk@mit.edu>
Thu, 21 Jul 2016 03:24:59 +0000 (23:24 -0400)
commitfa5af899319b69fa9542add78beca388521e3450
tree52e0b7c2f93f0bb3eb5fb13c3837195d01600099
parent75325fc9ab1cec4a338e1aaf1b32de1922492b12
SOLARIS: corrupted content of mmap'd files over 4GiB

Many Solaris programs and utilities (notably mdb and cp) use mmap() in
their implementation.  When AFS files exceeding 4GiB are mmap'd, the
contents of the file will be incorrectly mapped into memory. Starting at
4GiB + 1, the first 4GiB will be repeated for the remainder of the file.
If the mmap'd file is written back to storage (AFS or otherwise), the
newly created file will also be corrupted.

This is due to a bug in the afs_map() routine that supports mmap() of
AFS files on Solaris.  The segvn_crarg.offset passed to the Solaris
virtual memory APIs is incorrectly cast to u_int, causing it to wrap at
4GiB.

Although Solaris passes the offset from fop_map() to afs_map() as type
offset_t, the destination segvn_crargs.offset is actually type
u_offset_t.  Existing examples of other Solaris filesystems (e.g.
zfs_map() ) cast the offset from offset_t to u_offset_t when assigning to
segvn_crargs.offset.  If it's good enough for ZFS, it's good enough for
AFS.

Correctly cast the offset to u_offset_t.

Thanks to Robert Milkowski for the report and diagnosis.

Change-Id: Id25363255ec011f2ad7e003ca3e4a1385bebff7e
Reviewed-on: https://gerrit.openafs.org/12292
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
src/afs/SOLARIS/osi_vnodeops.c