udf: Fix 64-bit sign extension issues affecting blocks > 0x7FFFFFFF
authorSteve Magnani <steve.magnani@digidescorp.com>
Thu, 12 Oct 2017 13:48:40 +0000 (08:48 -0500)
committerJan Kara <jack@suse.cz>
Tue, 17 Oct 2017 09:56:45 +0000 (11:56 +0200)
commitb490bdd630cc43a5725e76c7c23f8a7e55551145
tree9ee95e0af7d247b2a8b282b2b5ed1a783465e9da
parent503c3117d05c184b431e403cd05c463ac41370f0
udf: Fix 64-bit sign extension issues affecting blocks > 0x7FFFFFFF

Large (> 1 TiB) UDF filesystems appear subject to several problems when
mounted on 64-bit systems:

* readdir() can fail on a directory containing File Identifiers residing
  above 0x7FFFFFFF. This manifests as a 'ls' command failing with EIO.

* FIBMAP on a file block located above 0x7FFFFFFF can return a negative
  value. The low 32 bits are correct, but applications that don't mask the
  high 32 bits of the result can perform incorrectly.

Per suggestion by Jan Kara, introduce a udf_pblk_t type for representation
of UDF block addresses. Ultimately, all driver functions that manipulate
UDF block addresses should use this type; for now, deployment is limited
to functions with actual or potential sign extension issues.

Changes to udf_readdir() and udf_block_map() address the issues noted
above; other changes address potential similar issues uncovered during
audit of the driver code.

Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
Signed-off-by: Jan Kara <jack@suse.cz>
fs/udf/balloc.c
fs/udf/dir.c
fs/udf/directory.c
fs/udf/ialloc.c
fs/udf/inode.c
fs/udf/misc.c
fs/udf/namei.c
fs/udf/super.c
fs/udf/truncate.c
fs/udf/udfdecl.h