summaryrefslogtreecommitdiff
path: root/fs/udf/directory.c
diff options
context:
space:
mode:
authorSteve Magnani <steve.magnani@digidescorp.com>2017-10-12 16:48:40 +0300
committerJan Kara <jack@suse.cz>2017-10-17 12:56:45 +0300
commitb490bdd630cc43a5725e76c7c23f8a7e55551145 (patch)
tree9ee95e0af7d247b2a8b282b2b5ed1a783465e9da /fs/udf/directory.c
parent503c3117d05c184b431e403cd05c463ac41370f0 (diff)
downloadlinux-b490bdd630cc43a5725e76c7c23f8a7e55551145.tar.xz
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>
Diffstat (limited to 'fs/udf/directory.c')
-rw-r--r--fs/udf/directory.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/fs/udf/directory.c b/fs/udf/directory.c
index 7aa48bd7cbaf..c41c3cc8e5c6 100644
--- a/fs/udf/directory.c
+++ b/fs/udf/directory.c
@@ -26,7 +26,8 @@ struct fileIdentDesc *udf_fileident_read(struct inode *dir, loff_t *nf_pos,
sector_t *offset)
{
struct fileIdentDesc *fi;
- int i, num, block;
+ int i, num;
+ udf_pblk_t block;
struct buffer_head *tmp, *bha[16];
struct udf_inode_info *iinfo = UDF_I(dir);