--- /dev/null
+From 9ee29d20aab228adfb02ca93f87fb53c56c2f3af Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Fri, 27 Mar 2026 02:13:15 -0400
+Subject: ext4: always drain queued discard work in ext4_mb_release()
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+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 <tytso@mit.edu>
+Fixes: 55cdd0af2bc5 ("ext4: get discard out of jbd2 commit kthread contex")
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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++) {
--- /dev/null
+From 46066e3a06647c5b186cc6334409722622d05c44 Mon Sep 17 00:00:00 2001
+From: Ye Bin <yebin10@huawei.com>
+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 <yebin10@huawei.com>
+
+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 <yebin10@huawei.com>
+Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
+Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
+Reviewed-by: Andreas Dilger <adilger@dilger.ca>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://patch.msgid.link/20260302134619.3145520-1-yebin@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)))
--- /dev/null
+From 5422fe71d26d42af6c454ca9527faaad4e677d6c Mon Sep 17 00:00:00 2001
+From: Edward Adam Davis <eadavis@qq.com>
+Date: Fri, 6 Mar 2026 09:31:58 +0800
+Subject: ext4: avoid infinite loops caused by residual data
+
+From: Edward Adam Davis <eadavis@qq.com>
+
+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 <eadavis@qq.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Tested-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
+Link: https://patch.msgid.link/tencent_43696283A68450B761D76866C6F360E36705@qq.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From ed9356a30e59c7cc3198e7fc46cfedf3767b9b17 Mon Sep 17 00:00:00 2001
+From: Deepanshu Kartikey <kartikey406@gmail.com>
+Date: Sat, 7 Feb 2026 10:06:07 +0530
+Subject: ext4: convert inline data to extents when truncate exceeds inline size
+
+From: Deepanshu Kartikey <kartikey406@gmail.com>
+
+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 <Kartikey406@gmail.com>
+Link: https://patch.msgid.link/20260207043607.1175976-1-kartikey406@gmail.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From ec0a7500d8eace5b4f305fa0c594dd148f0e8d29 Mon Sep 17 00:00:00 2001
+From: Baokun Li <libaokun@linux.alibaba.com>
+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 <libaokun@linux.alibaba.com>
+
+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 <joseph.qi@linux.alibaba.com>
+Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
+Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
+Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://patch.msgid.link/20260323060836.3452660-1-libaokun@linux.alibaba.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
+ /*
--- /dev/null
+From b1d682f1990c19fb1d5b97d13266210457092bcd Mon Sep 17 00:00:00 2001
+From: Simon Weber <simon.weber.39@gmail.com>
+Date: Sat, 7 Feb 2026 10:53:03 +0100
+Subject: ext4: fix journal credit check when setting fscrypt context
+
+From: Simon Weber <simon.weber.39@gmail.com>
+
+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 <anthonydev@fastmail.com>
+Signed-off-by: Anthony Durrer <anthonydev@fastmail.com>
+Signed-off-by: Simon Weber <simon.weber.39@gmail.com>
+Reviewed-by: Eric Biggers <ebiggers@kernel.org>
+Link: https://patch.msgid.link/20260207100148.724275-4-simon.weber.39@gmail.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From bd060afa7cc3e0ad30afa9ecc544a78638498555 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Mon, 16 Feb 2026 17:48:43 +0100
+Subject: ext4: make recently_deleted() properly work with lazy itable initialization
+
+From: Jan Kara <jack@suse.cz>
+
+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 <jack@suse.cz>
+Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
+Link: https://patch.msgid.link/20260216164848.3074-3-jack@suse.cz
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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))
--- /dev/null
+From 3822743dc20386d9897e999dbb990befa3a5b3f8 Mon Sep 17 00:00:00 2001
+From: Helen Koike <koike@igalia.com>
+Date: Tue, 17 Mar 2026 11:23:10 -0300
+Subject: ext4: reject mount if bigalloc with s_first_data_block != 0
+
+From: Helen Koike <koike@igalia.com>
+
+commit 3822743dc20386d9897e999dbb990befa3a5b3f8 upstream.
+
+bigalloc with s_first_data_block != 0 is not supported, reject mounting
+it.
+
+Signed-off-by: Helen Koike <koike@igalia.com>
+Suggested-by: Theodore Ts'o <tytso@mit.edu>
+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 <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) ||
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
