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>
(void)as_unmap(as, *addr, len); /* unmap old address space use */
/* setup the create parameter block for the call */
crargs.vp = AFSTOV(avc);
- crargs.offset = (u_int) off;
+ crargs.offset = (u_offset_t)off;
crargs.cred = cred;
crargs.type = flags & MAP_TYPE;
crargs.prot = prot;