potential integer truncation issues on 32 bit archs

potential integer truncation issues on 32 bit archs

[PaX Team]

Hi everyone,

while investigating some integer related error reports we got, i ran across
some code in both the VFS/MM and btrfs that i think raise a more generic problem.

in particular, when converting a file offset to a page cache index, the canonical
type of the latter is usually pgoff_t, typedef'ed to unsigned long (but i saw
unsigned long used directly as well). this can be problematic if the VFS or any
file system wants to support files over 16TB (say on i386) since after a shift
by PAGE_CACHE_SHIFT some MSBs will be lost on 32 bit archs (now this may not be
a supported use case but at least btrfs doesn't seem to exclude it). another
trigger seems to be vfs_fsync that passes LLONG_MAX and which can end up converted
to a page cache index (truncated on 32 bit archs).

my basic question is whether this is considered an actual problem and whether
there are already measures at some higher abstraction levels to prevent such
integer truncations and the use of incorrect page cache indices.

cheers,
 PaX Team

PS: two random examples:
    mm/filemap.c:filemap_fdatawait_range 
    fs/btrfs/extent_io.c:extent_range_clear_dirty_for_io

Re: potential integer truncation issues on 32 bit archs

[Dave Chinner]

On Sun, Oct 18, 2015 at 03:51:19PM +0200, PaX Team wrote:
> Hi everyone,
> 
> while investigating some integer related error reports we got, i ran across
> some code in both the VFS/MM and btrfs that i think raise a more generic problem.
> 
> in particular, when converting a file offset to a page cache index, the canonical
> type of the latter is usually pgoff_t, typedef'ed to unsigned long (but i saw
> unsigned long used directly as well). this can be problematic if the VFS or any
> file system wants to support files over 16TB (say on i386) since after a shift
> by PAGE_CACHE_SHIFT some MSBs will be lost on 32 bit archs (now this may not be
> a supported use case but at least btrfs doesn't seem to exclude it). another
> trigger seems to be vfs_fsync that passes LLONG_MAX and which can end up converted
> to a page cache index (truncated on 32 bit archs).

Files larger than 16TB are not supported on 32 bit arches. Most
filesystems limit fil size to 8TB (MAX_LFS_FILESIZE), though some
(e.g. XFS) limit it to (16TB - 1 byte).  Filesystems currently
enforce the 8/16TB file size limit on 32bit systems through
sb->s_maxbytes.

I very much doubt we'll ever change this because of all the
infrastructure changes needed. e.g.  radix trees need to be
converted to 64 bit indexes on 32 bit platforms. It's far easier for
people to use a 64 bit CPU than it is for use to extend 32 bit
system support....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com