From: Greg Kroah-Hartman Date: Mon, 30 Mar 2026 11:37:35 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v6.6.131~32 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e202ade5fbcb716fd3622cf39a6f387c9fbea0a7;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: ext4-always-drain-queued-discard-work-in-ext4_mb_release.patch ext4-avoid-allocate-block-from-corrupted-group-in-ext4_mb_find_by_goal.patch ext4-avoid-infinite-loops-caused-by-residual-data.patch ext4-convert-inline-data-to-extents-when-truncate-exceeds-inline-size.patch ext4-fix-iloc.bh-leak-in-ext4_fc_replay_inode-error-paths.patch ext4-fix-journal-credit-check-when-setting-fscrypt-context.patch ext4-make-recently_deleted-properly-work-with-lazy-itable-initialization.patch ext4-reject-mount-if-bigalloc-with-s_first_data_block-0.patch --- diff --git a/queue-6.1/ext4-always-drain-queued-discard-work-in-ext4_mb_release.patch b/queue-6.1/ext4-always-drain-queued-discard-work-in-ext4_mb_release.patch new file mode 100644 index 0000000000..34b85958e5 --- /dev/null +++ b/queue-6.1/ext4-always-drain-queued-discard-work-in-ext4_mb_release.patch @@ -0,0 +1,65 @@ +From 9ee29d20aab228adfb02ca93f87fb53c56c2f3af Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o +Date: Fri, 27 Mar 2026 02:13:15 -0400 +Subject: ext4: always drain queued discard work in ext4_mb_release() + +From: Theodore Ts'o + +commit 9ee29d20aab228adfb02ca93f87fb53c56c2f3af upstream. + +While reviewing recent ext4 patch[1], Sashiko raised the following +concern[2]: + +> If the filesystem is initially mounted with the discard option, +> deleting files will populate sbi->s_discard_list and queue +> s_discard_work. If it is then remounted with nodiscard, the +> EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is +> neither cancelled nor flushed. + +[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ +[2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev + +The concern was valid, but it had nothing to do with the patch[1]. +One of the problems with Sashiko in its current (early) form is that +it will detect pre-existing issues and report it as a problem with the +patch that it is reviewing. + +In practice, it would be hard to hit deliberately (unless you are a +malicious syzkaller fuzzer), since it would involve mounting the file +system with -o discard, and then deleting a large number of files, +remounting the file system with -o nodiscard, and then immediately +unmounting the file system before the queued discard work has a change +to drain on its own. + +Fix it because it's a real bug, and to avoid Sashiko from raising this +concern when analyzing future patches to mballoc.c. + +Signed-off-by: Theodore Ts'o +Fixes: 55cdd0af2bc5 ("ext4: get discard out of jbd2 commit kthread contex") +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/mballoc.c | 12 +++++------- + 1 file changed, 5 insertions(+), 7 deletions(-) + +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -3591,13 +3591,11 @@ int ext4_mb_release(struct super_block * + struct kmem_cache *cachep = get_groupinfo_cache(sb->s_blocksize_bits); + int count; + +- if (test_opt(sb, DISCARD)) { +- /* +- * wait the discard work to drain all of ext4_free_data +- */ +- flush_work(&sbi->s_discard_work); +- WARN_ON_ONCE(!list_empty(&sbi->s_discard_list)); +- } ++ /* ++ * wait the discard work to drain all of ext4_free_data ++ */ ++ flush_work(&sbi->s_discard_work); ++ WARN_ON_ONCE(!list_empty(&sbi->s_discard_list)); + + if (sbi->s_group_info) { + for (i = 0; i < ngroups; i++) { diff --git a/queue-6.1/ext4-avoid-allocate-block-from-corrupted-group-in-ext4_mb_find_by_goal.patch b/queue-6.1/ext4-avoid-allocate-block-from-corrupted-group-in-ext4_mb_find_by_goal.patch new file mode 100644 index 0000000000..8a034f69cb --- /dev/null +++ b/queue-6.1/ext4-avoid-allocate-block-from-corrupted-group-in-ext4_mb_find_by_goal.patch @@ -0,0 +1,92 @@ +From 46066e3a06647c5b186cc6334409722622d05c44 Mon Sep 17 00:00:00 2001 +From: Ye Bin +Date: Mon, 2 Mar 2026 21:46:19 +0800 +Subject: ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal() + +From: Ye Bin + +commit 46066e3a06647c5b186cc6334409722622d05c44 upstream. + +There's issue as follows: +... +EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 +EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost + +EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 +EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost + +EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 +EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost + +EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 +EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost + +EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 +EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost + +EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 +EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost + +EXT4-fs (mmcblk0p1): error count since last fsck: 1 +EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 +EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 +... + +According to the log analysis, blocks are always requested from the +corrupted block group. This may happen as follows: +ext4_mb_find_by_goal + ext4_mb_load_buddy + ext4_mb_load_buddy_gfp + ext4_mb_init_cache + ext4_read_block_bitmap_nowait + ext4_wait_block_bitmap + ext4_validate_block_bitmap + if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) + return -EFSCORRUPTED; // There's no logs. + if (err) + return err; // Will return error +ext4_lock_group(ac->ac_sb, group); + if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable + goto out; + +After commit 9008a58e5dce ("ext4: make the bitmap read routines return +real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group +as corrupt on block bitmap error") is no real solution for allocating +blocks from corrupted block groups. This is because if +'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then +'ext4_mb_load_buddy()' may return an error. This means that the block +allocation will fail. +Therefore, check block group if corrupted when ext4_mb_load_buddy() +returns error. + +Fixes: 163a203ddb36 ("ext4: mark block group as corrupt on block bitmap error") +Fixes: 9008a58e5dce ("ext4: make the bitmap read routines return real error codes") +Signed-off-by: Ye Bin +Reviewed-by: Ritesh Harjani (IBM) +Reviewed-by: Zhang Yi +Reviewed-by: Andreas Dilger +Reviewed-by: Jan Kara +Link: https://patch.msgid.link/20260302134619.3145520-1-yebin@huaweicloud.com +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/mballoc.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -2236,8 +2236,12 @@ int ext4_mb_find_by_goal(struct ext4_all + return 0; + + err = ext4_mb_load_buddy(ac->ac_sb, group, e4b); +- if (err) ++ if (err) { ++ if (EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info) && ++ !(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY)) ++ return 0; + return err; ++ } + + ext4_lock_group(ac->ac_sb, group); + if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) diff --git a/queue-6.1/ext4-avoid-infinite-loops-caused-by-residual-data.patch b/queue-6.1/ext4-avoid-infinite-loops-caused-by-residual-data.patch new file mode 100644 index 0000000000..266c29c448 --- /dev/null +++ b/queue-6.1/ext4-avoid-infinite-loops-caused-by-residual-data.patch @@ -0,0 +1,81 @@ +From 5422fe71d26d42af6c454ca9527faaad4e677d6c Mon Sep 17 00:00:00 2001 +From: Edward Adam Davis +Date: Fri, 6 Mar 2026 09:31:58 +0800 +Subject: ext4: avoid infinite loops caused by residual data + +From: Edward Adam Davis + +commit 5422fe71d26d42af6c454ca9527faaad4e677d6c upstream. + +On the mkdir/mknod path, when mapping logical blocks to physical blocks, +if inserting a new extent into the extent tree fails (in this example, +because the file system disabled the huge file feature when marking the +inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to +reclaim the physical block without deleting the corresponding data in +the extent tree. This causes subsequent mkdir operations to reference +the previously reclaimed physical block number again, even though this +physical block is already being used by the xattr block. Therefore, a +situation arises where both the directory and xattr are using the same +buffer head block in memory simultaneously. + +The above causes ext4_xattr_block_set() to enter an infinite loop about +"inserted" and cannot release the inode lock, ultimately leading to the +143s blocking problem mentioned in [1]. + +If the metadata is corrupted, then trying to remove some extent space +can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE +was passed, remove space wrongly update quota information. +Jan Kara suggests distinguishing between two cases: + +1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully +consistent and we must maintain its consistency including all the +accounting. However these errors can happen only early before we've +inserted the extent into the extent tree. So current code works correctly +for this case. + +2) Some other error - this means metadata is corrupted. We should strive to +do as few modifications as possible to limit damage. So I'd just skip +freeing of allocated blocks. + +[1] +INFO: task syz.0.17:5995 blocked for more than 143 seconds. +Call Trace: + inode_lock_nested include/linux/fs.h:1073 [inline] + __start_dirop fs/namei.c:2923 [inline] + start_dirop fs/namei.c:2934 [inline] + +Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7 +Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com +Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f +Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com +Signed-off-by: Edward Adam Davis +Reviewed-by: Jan Kara +Tested-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com +Link: https://patch.msgid.link/tencent_43696283A68450B761D76866C6F360E36705@qq.com +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/extents.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/fs/ext4/extents.c ++++ b/fs/ext4/extents.c +@@ -4424,9 +4424,13 @@ got_allocated_blocks: + path = ext4_ext_insert_extent(handle, inode, path, &newex, flags); + if (IS_ERR(path)) { + err = PTR_ERR(path); +- if (allocated_clusters) { ++ /* ++ * Gracefully handle out of space conditions. If the filesystem ++ * is inconsistent, we'll just leak allocated blocks to avoid ++ * causing even more damage. ++ */ ++ if (allocated_clusters && (err == -EDQUOT || err == -ENOSPC)) { + int fb_flags = 0; +- + /* + * free data blocks we just allocated. + * not a good idea to call discard here directly, diff --git a/queue-6.1/ext4-convert-inline-data-to-extents-when-truncate-exceeds-inline-size.patch b/queue-6.1/ext4-convert-inline-data-to-extents-when-truncate-exceeds-inline-size.patch new file mode 100644 index 0000000000..270596c53a --- /dev/null +++ b/queue-6.1/ext4-convert-inline-data-to-extents-when-truncate-exceeds-inline-size.patch @@ -0,0 +1,67 @@ +From ed9356a30e59c7cc3198e7fc46cfedf3767b9b17 Mon Sep 17 00:00:00 2001 +From: Deepanshu Kartikey +Date: Sat, 7 Feb 2026 10:06:07 +0530 +Subject: ext4: convert inline data to extents when truncate exceeds inline size + +From: Deepanshu Kartikey + +commit ed9356a30e59c7cc3198e7fc46cfedf3767b9b17 upstream. + +Add a check in ext4_setattr() to convert files from inline data storage +to extent-based storage when truncate() grows the file size beyond the +inline capacity. This prevents the filesystem from entering an +inconsistent state where the inline data flag is set but the file size +exceeds what can be stored inline. + +Without this fix, the following sequence causes a kernel BUG_ON(): + +1. Mount filesystem with inode that has inline flag set and small size +2. truncate(file, 50MB) - grows size but inline flag remains set +3. sendfile() attempts to write data +4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity) + +The crash occurs because ext4_write_inline_data() expects inline storage +to accommodate the write, but the actual inline capacity (~60 bytes for +i_block + ~96 bytes for xattrs) is far smaller than the file size and +write request. + +The fix checks if the new size from setattr exceeds the inode's actual +inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to +extent-based storage before proceeding with the size change. + +This addresses the root cause by ensuring the inline data flag and file +size remain consistent during truncate operations. + +Reported-by: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=7de5fe447862fc37576f +Tested-by: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com +Signed-off-by: Deepanshu Kartikey +Link: https://patch.msgid.link/20260207043607.1175976-1-kartikey406@gmail.com +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/inode.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -5551,6 +5551,18 @@ int ext4_setattr(struct user_namespace * + if (attr->ia_size == inode->i_size) + inc_ivers = false; + ++ /* ++ * If file has inline data but new size exceeds inline capacity, ++ * convert to extent-based storage first to prevent inconsistent ++ * state (inline flag set but size exceeds inline capacity). ++ */ ++ if (ext4_has_inline_data(inode) && ++ attr->ia_size > EXT4_I(inode)->i_inline_size) { ++ error = ext4_convert_inline_data(inode); ++ if (error) ++ goto err_out; ++ } ++ + if (shrink) { + if (ext4_should_order_data(inode)) { + error = ext4_begin_ordered_truncate(inode, diff --git a/queue-6.1/ext4-fix-iloc.bh-leak-in-ext4_fc_replay_inode-error-paths.patch b/queue-6.1/ext4-fix-iloc.bh-leak-in-ext4_fc_replay_inode-error-paths.patch new file mode 100644 index 0000000000..46f53a9c08 --- /dev/null +++ b/queue-6.1/ext4-fix-iloc.bh-leak-in-ext4_fc_replay_inode-error-paths.patch @@ -0,0 +1,84 @@ +From ec0a7500d8eace5b4f305fa0c594dd148f0e8d29 Mon Sep 17 00:00:00 2001 +From: Baokun Li +Date: Mon, 23 Mar 2026 14:08:36 +0800 +Subject: ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths + +From: Baokun Li + +commit ec0a7500d8eace5b4f305fa0c594dd148f0e8d29 upstream. + +During code review, Joseph found that ext4_fc_replay_inode() calls +ext4_get_fc_inode_loc() to get the inode location, which holds a +reference to iloc.bh that must be released via brelse(). + +However, several error paths jump to the 'out' label without +releasing iloc.bh: + + - ext4_handle_dirty_metadata() failure + - sync_dirty_buffer() failure + - ext4_mark_inode_used() failure + - ext4_iget() failure + +Fix this by introducing an 'out_brelse' label placed just before +the existing 'out' label to ensure iloc.bh is always released. + +Additionally, make ext4_fc_replay_inode() propagate errors +properly instead of always returning 0. + +Reported-by: Joseph Qi +Fixes: 8016e29f4362 ("ext4: fast commit recovery path") +Signed-off-by: Baokun Li +Reviewed-by: Zhang Yi +Reviewed-by: Jan Kara +Link: https://patch.msgid.link/20260323060836.3452660-1-libaokun@linux.alibaba.com +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/fast_commit.c | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +--- a/fs/ext4/fast_commit.c ++++ b/fs/ext4/fast_commit.c +@@ -1623,19 +1623,21 @@ static int ext4_fc_replay_inode(struct s + /* Immediately update the inode on disk. */ + ret = ext4_handle_dirty_metadata(NULL, NULL, iloc.bh); + if (ret) +- goto out; ++ goto out_brelse; + ret = sync_dirty_buffer(iloc.bh); + if (ret) +- goto out; ++ goto out_brelse; + ret = ext4_mark_inode_used(sb, ino); + if (ret) +- goto out; ++ goto out_brelse; + + /* Given that we just wrote the inode on disk, this SHOULD succeed. */ + inode = ext4_iget(sb, ino, EXT4_IGET_NORMAL); + if (IS_ERR(inode)) { + ext4_debug("Inode not found."); +- return -EFSCORRUPTED; ++ inode = NULL; ++ ret = -EFSCORRUPTED; ++ goto out_brelse; + } + + /* +@@ -1652,13 +1654,14 @@ static int ext4_fc_replay_inode(struct s + ext4_inode_csum_set(inode, ext4_raw_inode(&iloc), EXT4_I(inode)); + ret = ext4_handle_dirty_metadata(NULL, NULL, iloc.bh); + sync_dirty_buffer(iloc.bh); ++out_brelse: + brelse(iloc.bh); + out: + iput(inode); + if (!ret) + blkdev_issue_flush(sb->s_bdev); + +- return 0; ++ return ret; + } + + /* diff --git a/queue-6.1/ext4-fix-journal-credit-check-when-setting-fscrypt-context.patch b/queue-6.1/ext4-fix-journal-credit-check-when-setting-fscrypt-context.patch new file mode 100644 index 0000000000..586e63ece4 --- /dev/null +++ b/queue-6.1/ext4-fix-journal-credit-check-when-setting-fscrypt-context.patch @@ -0,0 +1,58 @@ +From b1d682f1990c19fb1d5b97d13266210457092bcd Mon Sep 17 00:00:00 2001 +From: Simon Weber +Date: Sat, 7 Feb 2026 10:53:03 +0100 +Subject: ext4: fix journal credit check when setting fscrypt context + +From: Simon Weber + +commit b1d682f1990c19fb1d5b97d13266210457092bcd upstream. + +Fix an issue arising when ext4 features has_journal, ea_inode, and encrypt +are activated simultaneously, leading to ENOSPC when creating an encrypted +file. + +Fix by passing XATTR_CREATE flag to xattr_set_handle function if a handle +is specified, i.e., when the function is called in the control flow of +creating a new inode. This aligns the number of jbd2 credits set_handle +checks for with the number allocated for creating a new inode. + +ext4_set_context must not be called with a non-null handle (fs_data) if +fscrypt context xattr is not guaranteed to not exist yet. The only other +usage of this function currently is when handling the ioctl +FS_IOC_SET_ENCRYPTION_POLICY, which calls it with fs_data=NULL. + +Fixes: c1a5d5f6ab21eb7e ("ext4: improve journal credit handling in set xattr paths") + +Co-developed-by: Anthony Durrer +Signed-off-by: Anthony Durrer +Signed-off-by: Simon Weber +Reviewed-by: Eric Biggers +Link: https://patch.msgid.link/20260207100148.724275-4-simon.weber.39@gmail.com +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/crypto.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/fs/ext4/crypto.c ++++ b/fs/ext4/crypto.c +@@ -169,10 +169,17 @@ static int ext4_set_context(struct inode + */ + + if (handle) { ++ /* ++ * Since the inode is new it is ok to pass the ++ * XATTR_CREATE flag. This is necessary to match the ++ * remaining journal credits check in the set_handle ++ * function with the credits allocated for the new ++ * inode. ++ */ + res = ext4_xattr_set_handle(handle, inode, + EXT4_XATTR_INDEX_ENCRYPTION, + EXT4_XATTR_NAME_ENCRYPTION_CONTEXT, +- ctx, len, 0); ++ ctx, len, XATTR_CREATE); + if (!res) { + ext4_set_inode_flag(inode, EXT4_INODE_ENCRYPT); + ext4_clear_inode_state(inode, diff --git a/queue-6.1/ext4-make-recently_deleted-properly-work-with-lazy-itable-initialization.patch b/queue-6.1/ext4-make-recently_deleted-properly-work-with-lazy-itable-initialization.patch new file mode 100644 index 0000000000..3693ddd6f5 --- /dev/null +++ b/queue-6.1/ext4-make-recently_deleted-properly-work-with-lazy-itable-initialization.patch @@ -0,0 +1,42 @@ +From bd060afa7cc3e0ad30afa9ecc544a78638498555 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Mon, 16 Feb 2026 17:48:43 +0100 +Subject: ext4: make recently_deleted() properly work with lazy itable initialization + +From: Jan Kara + +commit bd060afa7cc3e0ad30afa9ecc544a78638498555 upstream. + +recently_deleted() checks whether inode has been used in the near past. +However this can give false positive result when inode table is not +initialized yet and we are in fact comparing to random garbage (or stale +itable block of a filesystem before mkfs). Ultimately this results in +uninitialized inodes being skipped during inode allocation and possibly +they are never initialized and thus e2fsck complains. Verify if the +inode has been initialized before checking for dtime. + +Signed-off-by: Jan Kara +Reviewed-by: Zhang Yi +Link: https://patch.msgid.link/20260216164848.3074-3-jack@suse.cz +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/ialloc.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/fs/ext4/ialloc.c ++++ b/fs/ext4/ialloc.c +@@ -687,6 +687,12 @@ static int recently_deleted(struct super + if (unlikely(!gdp)) + return 0; + ++ /* Inode was never used in this filesystem? */ ++ if (ext4_has_group_desc_csum(sb) && ++ (gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT) || ++ ino >= EXT4_INODES_PER_GROUP(sb) - ext4_itable_unused_count(sb, gdp))) ++ return 0; ++ + bh = sb_find_get_block(sb, ext4_inode_table(sb, gdp) + + (ino / inodes_per_block)); + if (!bh || !buffer_uptodate(bh)) diff --git a/queue-6.1/ext4-reject-mount-if-bigalloc-with-s_first_data_block-0.patch b/queue-6.1/ext4-reject-mount-if-bigalloc-with-s_first_data_block-0.patch new file mode 100644 index 0000000000..58d42bf18f --- /dev/null +++ b/queue-6.1/ext4-reject-mount-if-bigalloc-with-s_first_data_block-0.patch @@ -0,0 +1,40 @@ +From 3822743dc20386d9897e999dbb990befa3a5b3f8 Mon Sep 17 00:00:00 2001 +From: Helen Koike +Date: Tue, 17 Mar 2026 11:23:10 -0300 +Subject: ext4: reject mount if bigalloc with s_first_data_block != 0 + +From: Helen Koike + +commit 3822743dc20386d9897e999dbb990befa3a5b3f8 upstream. + +bigalloc with s_first_data_block != 0 is not supported, reject mounting +it. + +Signed-off-by: Helen Koike +Suggested-by: Theodore Ts'o +Reported-by: syzbot+b73703b873a33d8eb8f6@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=b73703b873a33d8eb8f6 +Link: https://patch.msgid.link/20260317142325.135074-1-koike@igalia.com +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/super.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -3575,6 +3575,13 @@ int ext4_feature_set_ok(struct super_blo + "extents feature\n"); + return 0; + } ++ if (ext4_has_feature_bigalloc(sb) && ++ le32_to_cpu(EXT4_SB(sb)->s_es->s_first_data_block)) { ++ ext4_msg(sb, KERN_WARNING, ++ "bad geometry: bigalloc file system with non-zero " ++ "first_data_block\n"); ++ return 0; ++ } + + #if !IS_ENABLED(CONFIG_QUOTA) || !IS_ENABLED(CONFIG_QFMT_V2) + if (!readonly && (ext4_has_feature_quota(sb) || diff --git a/queue-6.1/series b/queue-6.1/series index 2ed686232d..63f1717726 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -109,3 +109,11 @@ dmaengine-sh-rz-dmac-move-chctrl-updates-under-spinlock.patch loongarch-workaround-ls2k-ls7a-gpu-dma-hang-bug.patch xfs-stop-reclaim-before-pushing-ail-during-unmount.patch xfs-fix-ri_total-validation-in-xlog_recover_attri_commit_pass2.patch +ext4-fix-journal-credit-check-when-setting-fscrypt-context.patch +ext4-convert-inline-data-to-extents-when-truncate-exceeds-inline-size.patch +ext4-make-recently_deleted-properly-work-with-lazy-itable-initialization.patch +ext4-avoid-infinite-loops-caused-by-residual-data.patch +ext4-avoid-allocate-block-from-corrupted-group-in-ext4_mb_find_by_goal.patch +ext4-reject-mount-if-bigalloc-with-s_first_data_block-0.patch +ext4-fix-iloc.bh-leak-in-ext4_fc_replay_inode-error-paths.patch +ext4-always-drain-queued-discard-work-in-ext4_mb_release.patch