kernel/linux.git/fs/ext4, branch v6.1.168

ext4: fix unused iterator variable warnings

2026-04-11T12:16:38+00:00

commit 856dd6c5981260b4d1aa84b78373ad54a203db48 upstream. When CONFIG_QUOTA is disabled, there are warnings around unused iterator variables: fs/ext4/super.c: In function 'ext4_put_super': fs/ext4/super.c:1262:13: error: unused variable 'i' [-Werror=unused-variable] 1262 | int i, err; | ^ fs/ext4/super.c: In function '__ext4_fill_super': fs/ext4/super.c:5200:22: error: unused variable 'i' [-Werror=unused-variable] 5200 | unsigned int i; | ^ cc1: all warnings being treated as errors The kernel has updated to GNU11, allowing the variables to be declared within the for loop. Do so to clear up the warnings. Fixes: dcbf87589d90 ("ext4: factor out ext4_flex_groups_free()") Signed-off-by: Nathan Chancellor Reviewed-by: Geert Uytterhoeven Reviewed-by: Jan Kara Reviewed-by: Jason Yan Link: https://lore.kernel.org/r/20230420-ext4-unused-variables-super-c-v1-1-138b6db6c21c@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman

ext4: fix lost error code reporting in __ext4_fill_super()

2026-04-11T12:16:38+00:00

commit d5e72c4e3256335d6fb75c2e321144f93141f4f5 upstream. When code was factored out of __ext4_fill_super() into ext4_percpu_param_init() the error return was discarded. This meant that it was possible for __ext4_fill_super() to return zero, indicating success, without the struct super getting completely filled in, leading to a potential NULL pointer dereference. Reported-by: syzbot+bbf0f9a213c94f283a5c@syzkaller.appspotmail.com Fixes: 1f79467c8a6b ("ext4: factor out ext4_percpu_param_init() ...") Link: https://syzkaller.appspot.com/bug?id=6dac47d5e58af770c0055f680369586ec32e144c Signed-off-by: Theodore Ts'o Reviewed-by: Jason Yan Signed-off-by: Greg Kroah-Hartman

ext4: handle wraparound when searching for blocks for indirect mapped blocks

2026-04-11T12:16:36+00:00

[ Upstream commit bb81702370fad22c06ca12b6e1648754dbc37e0f ] Commit 4865c768b563 ("ext4: always allocate blocks only from groups inode can use") restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers. However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern: If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal group was populated via stream allocation from s_mb_last_groups), then start will be >= ngroups. Does this allow allocating blocks beyond the 32-bit limit for indirect block mapped files? The commit message mentions that ext4_mb_scan_groups_linear() takes care to not select unsupported groups. However, its loop uses group = *start, and the very first iteration will call ext4_mb_scan_group() with this unsupported group because next_linear_group() is only called at the end of the iteration. After reviewing the code paths involved and considering the LLM review, I determined that this can happen when there is a file system where some files/directories are extent-mapped and others are indirect-block mapped. To address this, add a safety clamp in ext4_mb_scan_groups(). Fixes: 4865c768b563 ("ext4: always allocate blocks only from groups inode can use") Cc: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o Link: https://patch.msgid.link/20260326045834.1175822-1-tytso@mit.edu Signed-off-by: Theodore Ts'o Cc: stable@kernel.org [ adapted fix from ext4_mb_scan_groups() to inline equivalent in ext4_mb_regular_allocator() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: publish jinode after initialization

2026-04-11T12:16:36+00:00

[ Upstream commit 1aec30021edd410b986c156f195f3d23959a9d11 ] ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer. Fixes: a361293f5fede ("jbd2: Fix oops in jbd2_journal_file_inode()") Cc: stable@vger.kernel.org Signed-off-by: Li Chen Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260225082617.147957-1-me@linux.beauty Signed-off-by: Theodore Ts'o Cc: stable@kernel.org [ adapted READ_ONCE(jinode) wrapping to split ext4_fc_submit_inode_data_all() and ext4_fc_wait_inode_data_all() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: fix the might_sleep() warnings in kvfree()

2026-04-11T12:16:36+00:00

[ Upstream commit 496bb99b7e66f48b178126626f47e9ba79e2d0fa ] Use the kvfree() in the RCU read critical section can trigger the following warnings: EXT4-fs (vdb): unmounting filesystem cd983e5b-3c83-4f5a-a136-17b00eb9d018. WARNING: suspicious RCU usage ./include/linux/rcupdate.h:409 Illegal context switch in RCU read-side critical section! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 Call Trace: dump_stack_lvl+0xbb/0xd0 dump_stack+0x14/0x20 lockdep_rcu_suspicious+0x15a/0x1b0 __might_resched+0x375/0x4d0 ? put_object.part.0+0x2c/0x50 __might_sleep+0x108/0x160 vfree+0x58/0x910 ? ext4_group_desc_free+0x27/0x270 kvfree+0x23/0x40 ext4_group_desc_free+0x111/0x270 ext4_put_super+0x3c8/0xd40 generic_shutdown_super+0x14c/0x4a0 ? __pfx_shrinker_free+0x10/0x10 kill_block_super+0x40/0x90 ext4_kill_sb+0x6d/0xb0 deactivate_locked_super+0xb4/0x180 deactivate_super+0x7e/0xa0 cleanup_mnt+0x296/0x3e0 __cleanup_mnt+0x16/0x20 task_work_run+0x157/0x250 ? __pfx_task_work_run+0x10/0x10 ? exit_to_user_mode_loop+0x6a/0x550 exit_to_user_mode_loop+0x102/0x550 do_syscall_64+0x44a/0x500 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: sleeping function called from invalid context at mm/vmalloc.c:3441 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556, name: umount preempt_count: 1, expected: 0 CPU: 3 UID: 0 PID: 556 Comm: umount Call Trace: dump_stack_lvl+0xbb/0xd0 dump_stack+0x14/0x20 __might_resched+0x275/0x4d0 ? put_object.part.0+0x2c/0x50 __might_sleep+0x108/0x160 vfree+0x58/0x910 ? ext4_group_desc_free+0x27/0x270 kvfree+0x23/0x40 ext4_group_desc_free+0x111/0x270 ext4_put_super+0x3c8/0xd40 generic_shutdown_super+0x14c/0x4a0 ? __pfx_shrinker_free+0x10/0x10 kill_block_super+0x40/0x90 ext4_kill_sb+0x6d/0xb0 deactivate_locked_super+0xb4/0x180 deactivate_super+0x7e/0xa0 cleanup_mnt+0x296/0x3e0 __cleanup_mnt+0x16/0x20 task_work_run+0x157/0x250 ? __pfx_task_work_run+0x10/0x10 ? exit_to_user_mode_loop+0x6a/0x550 exit_to_user_mode_loop+0x102/0x550 do_syscall_64+0x44a/0x500 entry_SYSCALL_64_after_hwframe+0x77/0x7f The above scenarios occur in initialization failures and teardown paths, there are no parallel operations on the resources released by kvfree(), this commit therefore remove rcu_read_lock/unlock() and use rcu_access_pointer() instead of rcu_dereference() operations. Fixes: 7c990728b99e ("ext4: fix potential race between s_flex_groups online resizing and access") Fixes: df3da4ea5a0f ("ext4: fix potential race between s_group_info online resizing and access") Signed-off-by: Zqiang Reviewed-by: Baokun Li Link: https://patch.msgid.link/20260319094545.19291-1-qiang.zhang@linux.dev Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: factor out ext4_flex_groups_free()

2026-04-11T12:16:36+00:00

[ Upstream commit dcbf87589d90e3bd5a5a4cf832517f22f3c55efb ] Factor out ext4_flex_groups_free() and it can be used both in __ext4_fill_super() and ext4_put_super(). Signed-off-by: Jason Yan Link: https://lore.kernel.org/r/20230323140517.1070239-5-yanaijie@huawei.com Signed-off-by: Theodore Ts'o Stable-dep-of: 496bb99b7e66 ("ext4: fix the might_sleep() warnings in kvfree()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: use ext4_group_desc_free() in ext4_put_super() to save some duplicated code

2026-04-11T12:16:36+00:00

[ Upstream commit 6ef684988816fdfa29ceff260c97d725a489a942 ] The only difference here is that ->s_group_desc and ->s_flex_groups share the same rcu read lock here but it is not necessary. In other places they do not share the lock at all. Signed-off-by: Jason Yan Link: https://lore.kernel.org/r/20230323140517.1070239-4-yanaijie@huawei.com Signed-off-by: Theodore Ts'o Stable-dep-of: 496bb99b7e66 ("ext4: fix the might_sleep() warnings in kvfree()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: factor out ext4_percpu_param_init() and ext4_percpu_param_destroy()

2026-04-11T12:16:35+00:00

[ Upstream commit 1f79467c8a6be64940a699de1bd43338a6dd9fdd ] Factor out ext4_percpu_param_init() and ext4_percpu_param_destroy(). And also use ext4_percpu_param_destroy() in ext4_put_super() to avoid duplicated code. No functional change. Signed-off-by: Jason Yan Link: https://lore.kernel.org/r/20230323140517.1070239-3-yanaijie@huawei.com Signed-off-by: Theodore Ts'o Stable-dep-of: 496bb99b7e66 ("ext4: fix the might_sleep() warnings in kvfree()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: fix use-after-free in update_super_work when racing with umount

2026-04-11T12:16:34+00:00

[ Upstream commit d15e4b0a418537aafa56b2cb80d44add83e83697 ] Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups reads during unmount. However, this introduced a use-after-free because update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which accesses the kobject's kernfs_node after it has been freed by kobject_del() in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work) Instead of reordering the teardown sequence, fix this by making ext4_notify_error_sysfs() detect that sysfs has already been torn down by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call in that case. A dedicated mutex (s_error_notify_mutex) serializes ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs() to prevent TOCTOU races where the kobject could be deleted between the state_in_sysfs check and the sysfs_notify() call. Fixes: b98535d09179 ("ext4: fix bug_on in start_this_handle during umount filesystem") Cc: Jiayuan Chen Suggested-by: Jan Kara Signed-off-by: Jiayuan Chen Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260319120336.157873-1-jiayuan.chen@linux.dev Signed-off-by: Theodore Ts'o Cc: stable@kernel.org [ adapted mutex_init placement ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Revert "ext4: make ext4_es_remove_extent() return void"

2026-04-11T12:16:30+00:00

This reverts commit bfe24a48c1d56b046052014534bde1680fadb9dc. Signed-off-by: Sasha Levin