kernel/linux.git/fs/udf/directory.c, branch v6.19.11

udf: refactor inode_bmap() to handle error

2024-10-02T12:32:29+00:00

Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions. Reported-by: syzbot+7a4842f0b1801230a989@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7a4842f0b1801230a989 Tested-by: syzbot+7a4842f0b1801230a989@syzkaller.appspotmail.com Signed-off-by: Zhao Mengmeng Suggested-by: Jan Kara Signed-off-by: Jan Kara Link: https://patch.msgid.link/20241001115425.266556-4-zhaomzhao@126.com

udf: refactor udf_next_aext() to handle error

2024-10-02T12:10:50+00:00

Since udf_current_aext() has error handling, udf_next_aext() should have error handling too. Besides, when too many indirect extents found in one inode, return -EFSCORRUPTED; when reading block failed, return -EIO. Signed-off-by: Zhao Mengmeng Suggested-by: Jan Kara Signed-off-by: Jan Kara Link: https://patch.msgid.link/20241001115425.266556-3-zhaomzhao@126.com

udf: Fix -Wstringop-overflow warnings

2023-07-31T14:34:06+00:00

Use unsigned type in call to macro mint_t(). This avoids confusing the compiler about possible negative values that would cause the value in _len_ to wrap around. Fixes the following -Wstringop-warnings seen when building ARM architecture with allyesconfig (GCC 13): fs/udf/directory.c: In function 'udf_copy_fi': include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' specified bound between 2147483648 and 4294967295 exceeds maximum object size 2147483647 [-Wstringop-overflow=] 57 | #define __underlying_memcpy __builtin_memcpy | ^ include/linux/fortify-string.h:648:9: note: in expansion of macro '__underlying_memcpy' 648 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ include/linux/fortify-string.h:693:26: note: in expansion of macro '__fortify_memcpy_chk' 693 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ fs/udf/directory.c:99:9: note: in expansion of macro 'memcpy' 99 | memcpy(&iter->fi, iter->bh[0]->b_data + off, len); | ^~~~~~ include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' specified bound between 2147483648 and 4294967295 exceeds maximum object size 2147483647 [-Wstringop-overflow=] 57 | #define __underlying_memcpy __builtin_memcpy | ^ include/linux/fortify-string.h:648:9: note: in expansion of macro '__underlying_memcpy' 648 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ include/linux/fortify-string.h:693:26: note: in expansion of macro '__fortify_memcpy_chk' 693 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ fs/udf/directory.c:99:9: note: in expansion of macro 'memcpy' 99 | memcpy(&iter->fi, iter->bh[0]->b_data + off, len); | ^~~~~~ AR fs/udf/built-in.a This helps with the ongoing efforts to globally enable -Wstringop-overflow. Link: https://github.com/KSPP/linux/issues/329 Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Signed-off-by: Jan Kara Message-Id:

fs: udf: Replace GPL 2.0 boilerplate license notice with SPDX identifier

2023-05-30T13:39:13+00:00

The notice refers to full GPL 2.0 text on now defunct MIT FTP site [1]. Replace it with appropriate SPDX license identifier. Cc: Thomas Gleixner Cc: Pali Rohár Link: https://web.archive.org/web/20020809115410/ftp://prep.ai.mit.edu/pub/gnu/GPL [1] Signed-off-by: Bagas Sanjaya Signed-off-by: Jan Kara Message-Id: <20230522005434.22133-2-bagasdotme@gmail.com>

udf: Avoid directory type conversion failure due to ENOMEM

2023-02-09T09:37:12+00:00

When converting directory from in-ICB to normal format, the last iteration through the directory fixing up directory enteries can fail due to ENOMEM. We do not expect this iteration to fail since the directory is already verified to be correct and it is difficult to undo the conversion at this point. So just use GFP_NOFAIL to make sure the small allocation cannot fail. Reported-by: syzbot+111eaa994ff74f8d440f@syzkaller.appspotmail.com Fixes: 0aba4860b0d0 ("udf: Allocate name buffer in directory iterator on heap") Signed-off-by: Jan Kara

udf: Use unsigned variables for size calculations

2023-02-07T12:05:31+00:00

To avoid confusing the compiler about possible negative sizes, switch various size variables that can never be negative from int to u32. Seen with GCC 13: ../fs/udf/directory.c: In function 'udf_copy_fi': ../include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' pointer overflow between offset 80 and size [-2147483648, -1] [-Warray-bounds=] 57 | #define __underlying_memcpy __builtin_memcpy | ^ ... ../fs/udf/directory.c:102:9: note: in expansion of macro 'memcpy' 102 | memcpy(&iter->fi, iter->bh[0]->b_data + off, len); | ^~~~~~ Cc: Jan Kara Signed-off-by: Kees Cook Signed-off-by: Jan Kara Message-Id: <20230204183427.never.856-kees@kernel.org>

udf: Drop VARCONV support

2023-01-26T15:46:32+00:00

UDF was supporting a strange mode where the media was containing 7 blocks of unknown data for every 32 blocks of the filesystem. I have yet to see the media that would need such conversion (maybe it comes from packet writing times) and the conversions have been inconsistent in the code. In particular any write will write to a wrong block and corrupt the media. This is an indication and no user actually needs this so let's just drop the support instead of trying to fix it. Signed-off-by: Jan Kara

udf: Fix directory iteration for longer tail extents

2023-01-26T15:46:32+00:00

When directory's last extent has more that one block and its length is not multiple of a block side, the code wrongly decided to move to the next extent instead of processing the last partial block. This led to directory corruption. Fix the rounding issue. Signed-off-by: Jan Kara

udf: Propagate errors from udf_advance_blk()

2023-01-26T15:46:32+00:00

When we spot directory corruption when trying to load next directory extent, we didn't propagate the error up properly, leading to possibly indefinite looping on corrupted directories. Fix the problem by propagating the error properly. Signed-off-by: Jan Kara

udf: Zero udf name padding

2023-01-26T15:46:32+00:00

Padding of name in the directory entry needs to be zeroed out. Fix it. Signed-off-by: Jan Kara