- Jan 14, 2025
-
-
commit 1ea1cd11 upstream. 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 <jack@suse.cz> Cc: Shreenidhi Shedi <yesshedi@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
commit 32f123a3 upstream. udf_getblk() has a single call site. Fold it there. Signed-off-by:
Jakub Acs <acsjakub@amazon.de> Signed-off-by:
-
[ Upstream commit 264db9d6 ] Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 Reported-by:
<syzbot+8901c4560b7ab5c2f9df@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df Tested-by:
Jan Kara <jack@suse.com> Signed-off-by:
Gianfranco Trad <gianf.trad@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
[ Upstream commit ee703a70 ] As Jan suggested in links below, refactor udf_current_aext() to differentiate between error, hit EOF and success, it now takes pointer to etype to store the extent type, return 1 when getting etype success, return 0 when hitting EOF and return -errno when err. Link: https://lore.kernel.org/all/20240912111235.6nr3wuqvktecy3vh@quack3/ Signed-off-by:
Zhao Mengmeng <zhaomengmeng@kylinos.cn> Suggested-by:
-
commit df97f64d upstream. 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: 0aba4860 ("udf: Allocate name buffer in directory iterator on heap") Signed-off-by:
-
commit 0aba4860 upstream. Currently we allocate name buffer in directory iterators (struct udf_fileident_iter) on stack. These structures are relatively large (some 360 bytes on 64-bit architectures). For udf_rename() which needs to keep three of these structures in parallel the stack usage becomes rather heavy - 1536 bytes in total. Allocate the name buffer in the iterator from heap to avoid excessive stack usage. Link: https://lore.kernel.org/all/202212200558.lK9x1KW0-lkp@intel.com Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
[ Upstream commit f386c802 ] Nobody uses the bh returned from udf_expand_dir_adinicb(). Don't return it. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by:
-
[ Upstream commit 33e9a53c ] When there is an error when adding extent to the directory to expand it, make sure to propagate the error up properly. This is not expected to happen currently but let's make the code more futureproof. Signed-off-by:
-
[ Upstream commit 1e0290d6 ] Remove old directory iteration code that is now unused. Signed-off-by:
-
[ Upstream commit dbfb102d ] Convert udf_link() to use new directory iteration code for adding entry into the directory. Signed-off-by:
-
[ Upstream commit 00bce6f7 ] Convert udf_mkdir() to new directory iteration code. Signed-off-by:
-
[ Upstream commit ef91f999 ] Convert udf_add_nondir() to new directory iteration code. Signed-off-by:
-
[ Upstream commit f2844803 ] Implement function udf_fiiter_add_entry() adding new directory entries using new directory iteration code. Signed-off-by:
-
[ Upstream commit 6ec01a80 ] Convert udf_unlink() to new directory iteration code. Signed-off-by:
-
[ Upstream commit d11ffa8d ] Convert udf_rmdir() to use new directory iteration code. Signed-off-by:
-
[ Upstream commit afb525f4 ] Convert empty_dir() to new directory iteration code. Signed-off-by:
-
[ Upstream commit 9b06fbef ] Convert udf_get_parent() to use udf_fiiter_find_entry(). Signed-off-by:
-
[ Upstream commit 200918b3 ] Convert udf_lookup() to use udf_fiiter_find_entry() for looking up directory entries. Signed-off-by:
-
[ Upstream commit 7cd7a36a ] Convert udf_readdir() to new directory iteration functions. Signed-off-by:
-
[ Upstream commit e9109a92 ] Convert udf_rename() to use new directory iteration code. Reported-by:
<syzbot+0eaad3590d65102b9391@syzkaller.appspotmail.com> Reported-by:
<syzbot+b7fc73213bc2361ab650@syzkaller.appspotmail.com> Signed-off-by:
-
[ Upstream commit 4cca7e3d ] Provide function udf_fiiter_delete_entry() to mark directory entry as deleted using new directory iteration code. Signed-off-by:
-
[ Upstream commit 1c80afa0 ] Implement searching for directory entry - udf_fiiter_find_entry() - using new directory iteration code. Reported-by:
<syzbot+69c9fdccc6dd08961d34@syzkaller.appspotmail.com> Signed-off-by:
-
[ Upstream commit a27b2923 ] There is just one caller of udf_expand_dir_adinicb(). Move the function to its caller into namei.c as it is more about directory handling than anything else anyway. Signed-off-by:
-
[ Upstream commit 57bda9fb ] Convert udf_expand_dir_adinicb() to new directory iteration code. Signed-off-by:
-
[ Upstream commit d16076d9 ] Add new support code for iterating directory entries. The code is also more carefully verifying validity of on-disk directory entries to avoid crashes on malicious media. Signed-off-by:
-
[ Upstream commit ebbe26fd ] Avoid mounting filesystems where the partition would overflow the 32-bits used for block number. Also refuse to mount filesystems where the partition length is so large we cannot safely index bits in a block bitmap. Link: https://patch.msgid.link/20240620130403.14731-1-jack@suse.cz Signed-off-by:
-
- Sep 17, 2024
-
-
Jan Kara authored
commit c2efd13a upstream. UDF disk format supports in principle file sizes up to 1<<64-1. However the file space (including holes) is described by a linked list of extents, each of which can have at most 1GB. Thus the creation and handling of extents gets unusably slow beyond certain point. Limit the file size to 4TB to avoid locking up the kernel too easily. Signed-off-by:
-
Jan Kara authored
[ Upstream commit 27ab3385 ] Syzbot reports uninitialized memory access in udf_rename() when updating checksum of '..' directory entry of a moved directory. This is indeed true as we pass on-stack diriter.fi to the udf_update_tag() and because that has only struct fileIdentDesc included in it and not the impUse or name fields, the checksumming function is going to checksum random stack contents beyond the end of the structure. This is actually harmless because the following udf_fiiter_write_fi() will recompute the checksum from on-disk buffers where everything is properly included. So all that is needed is just removing the bogus calculation. Fixes: e9109a92 ("udf: Convert udf_rename() to new directory iteration code") Link: https://lore.kernel.org/all/000000000000cf405f060d8f75a9@google.com/T/ Link: https://patch.msgid.link/20240617154201.29512-1-jack@suse.cz Reported-by:
<syzbot+d31185aa54170f7fc1f5@syzkaller.appspotmail.com> Signed-off-by:
-
Roman Smirnov authored
[ Upstream commit 56e69e59 ] An overflow may occur if the function is called with the last block and an offset greater than zero. It is necessary to add a check to avoid this. Found by Linux Verification Center (linuxtesting.org) with Svace. [JK: Make test cover also unalloc table freeing] Link: https://patch.msgid.link/20240620072413.7448-1-r.smirnov@omp.ru Suggested-by:
Roman Smirnov <r.smirnov@omp.ru> Signed-off-by:
-
- Aug 12, 2024
-
-
commit a90d4471 upstream. When the filesystem block bitmap is corrupted, we detect the corruption while loading the bitmap and fail the allocation with error. However the next allocation from the same bitmap will notice the bitmap buffer is already loaded and tries to allocate from the bitmap with mixed results (depending on the exact nature of the bitmap corruption). Fix the problem by using BH_verified bit to indicate whether the bitmap is valid or not. Reported-by:
<syzbot+5f682cd029581f9edfd1@syzkaller.appspotmail.com> CC: stable@vger.kernel.org Link: https://patch.msgid.link/20240617154201.29512-2-jack@suse.cz Fixes: 1e0d4adf ("udf: Check consistency of Space Bitmap Descriptor") Signed-off-by:
-
- Jul 11, 2024
-
-
[ Upstream commit 3b84adf4 ] An overflow can occur in a situation where src.centiseconds takes the value of 255. This situation is unlikely, but there is no validation check anywere in the code. Found by Linux Verification Center (linuxtesting.org) with Svace. Suggested-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by:
-
- Oct 12, 2023
-
-
commit 23970a1c upstream. The clang build reports this error fs/udf/inode.c:805:6: error: variable 'newblock' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] if (*err < 0) ^~~~~~~~ newblock is never set before error handling jump. Initialize newblock to 0 and remove redundant settings. Fixes: d8b39db5fab8 ("udf: Handle error when adding extent to a file") Reported-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
commit 19fd80de upstream. When adding extent to a file fails, so far we've silently squelshed the error. Make sure to propagate it up properly. Signed-off-by:
-
commit 1e0d4adf upstream. Bits, which are related to Bitmap Descriptor logical blocks, are not reset when buffer headers are allocated for them. As the result, these logical blocks can be treated as free and be used for other blocks.This can cause usage of one buffer header for several types of data. UDF issues WARNING in this situation: WARNING: CPU: 0 PID: 2703 at fs/udf/inode.c:2014 __udf_add_aext+0x685/0x7d0 fs/udf/inode.c:2014 RIP: 0010:__udf_add_aext+0x685/0x7d0 fs/udf/inode.c:2014 Call Trace: udf_setup_indirect_aext+0x573/0x880 fs/udf/inode.c:1980 udf_add_aext+0x208/0x2e0 fs/udf/inode.c:2067 udf_insert_aext fs/udf/inode.c:2233 [inline] udf_update_extents fs/udf/inode.c:1181 [inline] inode_getblk+0x1981/0x3b70 fs/udf/inode.c:885 Found by Linux Verification Center (linuxtesting.org) with syzkaller. [JK: Somewhat cleaned up the boundary checks] Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Vladislav Efanov <VEfanov@ispras.ru> Signed-off-by:
-
- Aug 17, 2023
-
-
[ Upstream commit 028f6055 ] For filenames that begin with . and are between 2 and 5 characters long, UDF charset conversion code would read uninitialized memory in the output buffer. The only practical impact is that the name may be prepended a "unification hash" when it is not actually needed but still it is good to fix this. Reported-by:
<syzbot+cd311b1e43cc25f90d18@syzkaller.appspotmail.com> Link: https://lore.kernel.org/all/000000000000e2638a05fe9dc8f9@google.com Signed-off-by:
-
- Mar 17, 2023
-
-
Jan Kara authored
[ Upstream commit f54aa97f ] The condition determining whether the preallocation can be used had an off-by-one error so we didn't discard preallocation when new allocation was just following it. This can then confuse code in inode_getblk(). CC: stable@vger.kernel.org Fixes: 16d05565 ("udf: Discard preallocation before extending file with a hole") Signed-off-by:
-
- Mar 10, 2023
-
-
Jan Kara authored
commit 36ec52ea upstream. When we append new block just after the end of preallocated extent, the code in inode_getblk() wrongly determined we're going to use the preallocated extent which resulted in adding block into a wrong logical offset in the file. Sequence like this manifests it: xfs_io -f -c "pwrite 0x2cacf 0xd122" -c "truncate 0x2dd6f" \ -c "pwrite 0x27fd9 0x69a9" -c "pwrite 0x32981 0x7244" <file> The code that determined the use of preallocated extent is actually stale because udf_do_extend_file() does not create preallocation anymore so after calling that function we are sure there's no usable preallocation. Just remove the faulty condition. CC: stable@vger.kernel.org Fixes: 16d05565 ("udf: Discard preallocation before extending file with a hole") Signed-off-by:
-
Jan Kara authored
commit 85a37983 upstream. When UDF filesystem is corrupted, hidden system inodes can be linked into directory hierarchy which is an avenue for further serious corruption of the filesystem and kernel confusion as noticed by syzbot fuzzed images. Refuse to access system inodes linked into directory hierarchy and vice versa. CC: stable@vger.kernel.org Reported-by:
<syzbot+38695a20b8addcbc1084@syzkaller.appspotmail.com> Signed-off-by:
-
Jan Kara authored
commit fc8033a3 upstream. System files in UDF filesystem have link count 0. To not confuse VFS we fudge the link count to be 1 when reading such inodes however we forget to restore the link count of 0 when writing such inodes. Fix that. CC: stable@vger.kernel.org Signed-off-by:
-
Jan Kara authored
commit 256fe416 upstream. When write to inline file fails (or happens only partly), we still updated length of inline data as if the whole write succeeded. Fix the update of length of inline data to happen only if the write succeeds. Reported-by:
<syzbot+0937935b993956ba28ab@syzkaller.appspotmail.com> CC: stable@vger.kernel.org Signed-off-by:
-
